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1 .0 INTRODUCTION 

The Ground Operations Aerospace Language (GOAL) was designed to be used 
by test oriented personnel to write procedures which would be executed 
in a test environment. A series of discussions between NASA LV-CAP 
personnel and IBM resulted in some peripheral tasks which would aid in 
evaluating the applicability of the language in this environment, and 
provide enhancement for future applications. The results of these tasks 
are contained within this volume. 

The GOAL vocabulary provides a high degree of readability and retainability. 
To achieve these benefits, however, the procedure writer utilizes words and 
phrases of considerable length. Brief form study was undertaken to deter- 
mine a means of relieving this burden. The study resulted in a version of 
GOAL which enables the writer to develop a dialect suitable to his needs 
and satisfy the syntax equations. The output of the compiler would continue 
to provide readability by printing out the standard GOAL language. This 
task is described in Section 2.0. 

Section 3.0 provides the results of a study which identifies and recommends 
resolution of general problems associated with using engineering units in 
the GOAL language. A candidate set of units to support the terminology of 
various engineering disciplines is identified, and methods for input/output 
scaling of these units to the MKS system are recommended. 

Section 4.0 defines validation requirements and techniques for passing 
parameters to subroutines. Validation procedures are defined for sub- 
routine writers, subroutine users, and for configuration control via. the 
Data Bank. Implementation techniques are defined for the Data Bank and the 
Compiler. 

Several current automated procedures were manually converted to the GOAL 
language to verify the adaptability of the language to the environment. 
Section 5.0 discusses this conversion and provides examples of the results. 

The final section of the volume. Section 6.0, defines the use of system 
macros to facilitate frequently required and^r complex GOAL sequences. 
Several macros were developed and are demonstrated to show feasibility. 
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SECTION 2.0 
GOAL SHORT FORMS 
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2.1 


INTRODUCTION 


The GOAL compiler has the capability of processing test procedures written 
in the GOAL language and/or a suitable alternative language. The alternate 
language may be a 'shorthand' form of GOAL or even a foreign language. The 
present version of the compiler provides a short form vocabulary for use in 
writing GOAL test procedures. Table 2-1 contains two lists of all GOAL words 
and phrases with their corresponding short form alternates. The first list 
is in the order of the GOAL syntax equations. The second list is in alpha- 
betical order of the GOAL words and phrases. 

2.2 GUIDELINES FOR DEVELOPING A PARSABLE ALTERNATIVE VOCABULARY 

2.2.1 GOAL Parsing Technique 

The parsing of GOAL statements is controlled by the syntax table developed 
from the MBNF syntax equations. The compiler uses a table guided top-down 
parsing algorithm. The syntax table guides the parser in scanning state- 
ments in the input stream. Permissible constructions are recognized 
according to the contents of the syntax table. The recognition criterion 
is simple appearance. If a construction is not recognized, alternate 
definitions are tested. 

EXAMPLE: 


<G0AL STMT> = <SYSTEM STMT> | 

<PR0CEDURAL STMT> \ 

<DECLARATI0N STMT>; 

The syntax table will guide the parser through all system statements until 
a permissible construction is identified. If the construction is not 
recognized as a system statement then the parser will test the construction 
against the procedural and then the declaration statements. 

The technique Implies that keyword verbs must be unique in the order of 
appearance. For instance, if 'AB' were the first system statement keyword 
verb, then no alternate statement keyword could be composed of 'AB' as the 
first two characters. 

EXAMPLE: 

<SYSTEM STMT> = <KEYW0RD 1> 1 
<KEYW0RD 2> | 

<KEYW0RD 3> i 
<KEYW0RD 1> = 'AB' ; 

<KEYW0RD 2> = 'ABC ; 

<KEYW0RD 3> = 'A' ; 
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Keywords 1 and 3 will be recognized by the parser. However, keyword 2 
will never be recognized because of the lack of uniqueness in the order 
of keyword appearance. That is, whenever keyword 2, 'ABC, is parsed 
it will satisfy the keyword 1 equation. 

The following equations show the required order of appearance of key- 
words for proper parsing. 


<SYSTEM STMT> = <KEYW0RD 1> | 
<KEYW0RD 2> ] 
<KEYW0RD 3> ; 
<KEYW0RD 1> = 'ABC ; 

<KEYW0RD 2> = 'AB' ; 

<KEYW0RD 3> = 'A' ; 


The above equations will enable parsing of either of the three keywords 
because the keywords are now unique in the order of their appearances 
in the equations. 

2.3 IMPLEMENTING AN ALTERNATIVE VOCABULARY 

A particular alternative vocabulary is implemented through the GOAL 
modified Bachus Naur Form syntax equations. More specifically, the 
implementation is accomplished by substituting or including alternative 
text in the GOAL vocabulary syntax equations. 

There are five groups of syntax equations which contain all of the GOAL 
vocabulary. 

0 System statement Keywords 

0 Prefix Keywords 

0 Procedural Statement Keywords 

0 Declaration Statement Keywords 

0 GOAL Words and Phrases 

The method of implementing an alternative vocabulary is the same for 
either group. 


2-2 



The GOAL vocabulary and an alternative vocabulary may appear in the MBNF 
syntax equations in three forms as follows: 

Form 1. <X> = 'T1 ' ; 

Where X is the symbolic name of a GOAL word or phrase and T1 is the text 
for the GOAL word or phrase. The Form 1 equation makes no provision for 
alternatives to the GOAL words and phrases. 

Form 2. <X> = 'TT | <Z> ; 

<Z> = R1 'T2' R2 i 

Where X and T1 are the same as in Form 1, Z is the symbolic name of an 
alternate for Tl. T2 is the alternative text for Tl. R1 and R2 are action 
subroutines, called by the parser, which accomplish the substitution of 
GOAL words and phrases, Tl, for corresponding alternates, T2. 

Form 3. <X> = <Y> | <Z> ; 

<Y> = 'TT 'S'? ; 

<Z> = R1 'T2' R3 ; 

Where X, Z, Tl, Rl, T2 are as previously defined. Y is the symbolic name 
of an optionally plural GOAL word. R3 is the action routine, called by 
the parser, which appends the letter S to the GOAL word if the alternative 
word is pluralized. Care must be taken not to make a word optionally 
plural whenever the next word in the statement begins with the letter S. 

2.4 EXAMPLES OF MBNF EQUATIONS 

Form 1 is used when there is to be no alternate for the GOAL word or phrase. 
<BEGIN> = 'BEGIN' ; 

Form 2 is used when there is an alternate for the GOAL word or phrase, 
<BEGIN> = 'BEGIN' | <C001> ; 

<C001> = #5101 'BGN' #5102 ; 

The Form 2 equation enables parsing of either the word BEGIN or BGN. If 
the user has specified the compiler directive for substituting GOAL words 
and phrases for their alternates, then the word BGN will be replaced by 
BEGIN. 
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Forms is used when there is a short form for an optionally plural GOAL 
word or phrase. 

<C0LUMNS> = <C077> | <C078> ; 

<C077> = ’COLUMN’ 'S’? ; 

<C078> = #5101 ’C’ #5103 ; 

The Form 3 equation enables parsing of the words COLUMN, COLUMNS, C and 
CS. If the user has specified the compiler directive for substituting 
GOAL words and phrases for their alternates, then the words C and CS will 
be replaced by COLUMN and COLUMNS respectively. 

2.5 EXAMPLES OF STATEMENTS USING ALTERNATIVE WORDS AND CONVERSION 

TO THE GOAL VOCABULARY 

a. BGN PGM: 
converts to, 

BEGIN PROGRAM: 

b. STP , SI 90, S200; 
converts to, 

STOP AND INDICATE RESTART LABELS STEP 190, STEP200; 

Note: LABELS is followed by a word beginning with 

the letter S and therefore cannot be optionally 
plural. 

c. DCL STA TAB (WATER VALVE) 

W 1 R AND 2 CS 

TTL (OPEN), (CLOSED) WE 

<WVON> , (ON) , (OFF) ; 

converts to, 

DECLARE STATE TABLE (WATER VALVE) 

WITH 1 ROW AND 2 COLUMNS 

TITLED (OPEN), (CLOSED) WITH ENTRIES 

<WVON> , (ON) . (OFF) ; 
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2.6 IMPLEMENTING AN ALTERNATIVE VOCABULARY 

To implement an alternative vocabulary one must select a Form 2 or Form 3 
equation for each alternate word or phrase to be accommodated by the GOAL 
compiler. Then by following the procedures in paragraphs 2.3 and 2.4 above 
the MBNF syntax equations are written to describe a particular vocabulary. 
These equations, when keypunched, are used to replace corresponding 
equations in the GOAL Syntax Equation Table. This modified table is then 
used to generate a uniquely numbered GOAL compiler syntax table. This 
table will control parsing by the GOAL compiler when the table number is 
specified to the compiler at compile time, enabling statements written in 
the alternative vocabulary to be parsed and/or converted to the GOAL 
vocabulary. 

2.7 IMPLEMENTING ERROR MESSAGES 

Whenever errors are detected by the GOAL compiler, appropriate messages 
are listed for the test engineer to assist him in developing syntactically 
and semantically correct test procedures. These messages are contained in 
the GOAL error message file and are written in the context of the GOAL 
vocabulary. For example: 

error number 925 states, 

KEYWORD NOT FOUND - COLUMNS. 

error number 100 states, 

INVALID ROW DESIGNATOR OR KEYWORD 'ROW IS MISSING 

When an alternative vocabulary is to be implemented an error message file 
should be developed in terms of that vocabulary. The GOAL error message 
file is the baseline for developing error messages for an alternative 
vocabulary. The error message numbers are not to be changed. It is 
recommended that a distinct error message file be developed for each 
alternative to the GOAL vocabulary. The appropriate error file, GOAL 
or alternative error file, can be selected at compile time for use by 
the GOAL compiler. 

ERROR MESSAGE CARD FORMAT 

COLUMN 1, 2 AND 3 - Three digit error number. 

COLUMN 5 through 80 - The error message. 

2.8 GOAL SHORT FORM EXAMPLE 

Figure 2-1 is the GOAL Compiler listing of a test procedure which was 
written in short form GOAL. This test procedure is a portion of the 
Instrument Unit Mechanical Systems Procedure for support of lU Stage 
Power. The test procedure was compiled under the user option to 
convert from the short form to GOAL. 
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Table 2-1 


SHORT FORM LIST 1 

* SYSTEM STATEMENT KEYWORDS 

* GOAL 
BEGIN 
MACRO 
PROGRAM 
SUBROUTINE 
END 

EXECUTE 

EXPAND 

EXPAND AND EXECUTE 

FREE 

REPLACE 

USE 


* SHORT FORM 
BGN 
MAC 
PGM 
SUB 
END 
XEC 
XPD 
XAX 
FRE 
RPL 
USE 


* PREFIX KEYWORDS 

* GOAL 
STEP 
S 

AFTER 

WHEN 

VERIFY 

IF 


* SHORT FORM 
STEP 
S 

AFR 

WHN 

VFY 

IF 
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Table 2-1 
(Continued) 


PROCEDURAL STATEMENT KEYWORDS 


GOAL 

* SHORT FORM 

ACTIVATE 

ACT 

APPLY 

APA 

SEND 

SDA 

ASSIGN 

ASN 

AVERAGE 

AVG 

EVERY 

EVY 

CONCURRENTLY 

CNC 

DELAY 

DLY 

WAIT 

WTE 

DISABLE 

DBL 

GO TO 

GTO 

INHIBIT 

INH 

ISSUE 

ISU 

LEAVE 

LVE 

LET 

LET 

PERFORM 

PER 

CRITICAL 

CTL 

READ 

RDE 

MEASURE 

MSR 

DISPLAY 

DSP 

PRINT 

PRT 

RECORD 

RCD 

RELEASE 

RLS 

REPEAT 

REP 
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Table 2-1 
(Continued) 


REQUEST 

REQ 

RESUME 

RSM 

SET 

SET 

OPEN 

OPN 

CLOSE 

CLO 

TURN ON 

TON 

TURN OFF 

TFF 

STOP 

STP 

TERMINATE 

TRM 

SYSTEM 

SYS 

WHEN INTERRUPT 

WNT 


* DECLARATION STATEMENT KEYWORDS 
DECLARE 
NUMBER 
QUANTITY 
STATE 
TEXT 

NUMERIC LIST 
QUANTITY LIST 
STATE LIST 
TEXT LIST 
NUMERIC TABLE 
QUANTITY TABLE 
STATE TABLE 
TEXT TABLE 


DCL 
NBR 
QTY 
STA 
TXT 
RC LST 
QTY LST 
STA LST 
TXT LST 
NRC TAB 
QTY TAB 
STA TAB 
TXT TAB 
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Table 2-1 
(Continued) 


* GOAL WORDS AND PHRASES 

* SOAL * SHORT FORM 

ALL ALL 

AND AND 

AND INDICATE RESTART LABELS 

AND SAVE AS ASA 

ARE ARE 

B B 

BETWEEN BTW 

(1) CHARACTERS CHRS 

CLOSED CLD 

(1) COLUMNS CS 

(1) DAYS DAYS 

ELSE ELSE 

ENTRIES E 

ENTRY E 

EQUAL TO EQ 

(1) EXCEPTIONS XCPS 

FALSE false 

FOR FOR 

FROM FROM 

FUNCTIONS FNS 

GREATER THAN 6T 

GREATER THAN OR EQUAL TO GEQ 

(1) HRS HRS 
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Table 2-1 
(Continued) 


IS IS 

LESS THAN LT 

LESS THAN OR EQUAL TO LEQ 

(1) MINS MINS 

(1) MSECS MSECS 

NOT NOT 

NOT EQUAL TO NEQ 

OCCURS 

OFF OFF 

ON ON 

OR OR 

PRESENT VALUE OF PV 

READINGS OF RO 

RETURN RTN 

REVISION REV 

(1) ROWS RS 

(1) SECS SECS 

T T 

TEXT TXT 

THEN THEN or , 

THROUGH 

TIMES TMS 

TITLED TTL 

TO TO 
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Table 2-1 
(Continued) 


TRUE true 

UNTIL TIL 

(1) USING MESSAGES MSGS 

WITH W 

WITH A MAXIMUM OF WMAX 

WITH ENTRIES WE 

WITHIN WIN 

X X 


Note (1) - The letter S is optional 



SHORT FORM LIST 2 

* ALPHABETICAL LISTING 

* GOAL 
ACTIVATE 
AFTER 
ALL 



AND 

AND INDICATE RESTART LABELS 

AND SAVE AS 

APPLY 


ARE 


ASSIGN 

AVERAGE 


B 


BEGIN 

BETWEEN 

(1) CHARACTERS 
CLOSE 
CLOSED 
{ 1 ) COLUMNS 

CONCURRENTLY 
CRITICAL 
(1) DAYS 
DECLARE 
DELAY 
DISABLE 
DISPLAY 


* SHORT FORM 
ACT 
AFR 
ALL 
AND 
» 

ASA 

APA 

ARE 

ASN 

AVG 

B 

BGN 

BTW 

CHRS 

CLO 

CLD 

CS 

CNC 

CTL 

DAYS 

DCL 

DLY 

DBL 

DSP 


2-12 



Table 2-1 
(Continued) 


else else 

END end 

ENTRIES E 

ENTRY E 

EQUAL TO EQ 

EVERY EVY 

(1) EXCEPTIONS XCPS 

EXECUTE XEC 

EXPAND XPD 

EXPAND AND EXECUTE XAX 

FALSE FALSE 

FOR for 

FREE FRE 

FROM from 

FUNCTIONS FNS 

GO TO GTO 

GREATER THAN GT 

GREATER THAN OR EQUAL TO GEQ 

(1) HRS HRS 

IF IF 

INHIBIT INH 

IS IS 

ISSUE ISU 

LEAVE LVE 

LESS THAN LT 

LESS THAN OR EQUAL TO LEQ 
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Table 2-1 
(Continued) 


LET 
MACRO 
MEASURE 
(1) MINS 
(1) MSECS 
NOT 

NOT EQUAL TO 

NUMBER 

NUMERIC LIST 

NUMERIC TABLE 

OCCURS 

OFF 

ON 

OPEN 

OR 

PERFORM 

PRESENT VALUE OF 

PRINT 

PROGRAM 

QUANTITY 

QUANTITY LIST 

QUANTITY TABLE 

READ 

READINGS OF 

RECORD 

RELEASE 


LET 
MAC 
MSR 
MINS 
MSECS 
NOT 
NEQ 
NBR 
RC LST 
NRC TAB 
> 

OFF 

ON 

OPN 

OR 

PER 

PV 

PRT 

PGM 

QTY 

QTY LST 

QTY TAB 

RDE 

RO 

RCD 

RLS 


2-14 



Table 2-1 
(Continued) 


REPEAT 
REPLACE 
REQUEST 
RESUME 
RETURN 
REVISION 
(1) ROWS 
S 

(1) SECS 
SEND 
SET 
STATE 

STATE LIST 
STATE TABLE 
STEP 
STOP 

SUBROUTINE 

SYSTEM 

T 

TERMINATE 

TEXT 

TEXT LIST 
TEXT TABLE 
THEN 
THROUGH 


REP 

RPL 

QT 

RSM 

RTN 

REV 

RS 

S 

SECS 

SDA 

SET 

STA 

STA LST 

STA TAB 

STEP 

STP 

SUB 

SYS 

T 

TRM 

TXT 

TXT LST 
TXT TAB 
THEN or , 
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Table 2-1 
(Continued) 

TIMES TMS 

TITLED TTL 

TO TO 

TRUE TRUE 

TURN ON TON 

TURN OFF TFF 

UNTIL TIL 

USE USE 

(1) USING MESSAGES MSGS 

VERIFY VFY 

WAIT WTE 

WHEN WHN 

WHEN INTERRUPT WNT 

WITH W 

WITH A MAXIMUM OF WMAX 

WITH ENTRIES WE 

WITHIN WIN 

X X 


Note (1) - The letter S is optional 
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cccccccccc 

000000000000 

NN 

NN 

VV 

vv 

RRRRRRRRRRR 

TTTTTTTTTTTT 

cccccccccccc 

000000000000 

NNN 

NN 

vv 

vv 

RRRRRRRRRRRR 

TTTTTTTTTTTT 

cc cc 

00 

00 

NNNN 

NN 

VV 

vv 

RR 

RR 

TT 

cc 

00 

00 

NN NN 

NN 

vv 

vv 
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RR 
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00 
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GOAL COMPILER SOURCE RECORD LISTING 


RECORD SOURCE RECORD 


ro 

r 

CX) 


t 

2 

3 

4 

5 

6 
7 

a 

9 

10 

11 

12 

13 

14 

15 

16 
17 
IB 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 
36 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 

50 


BGN PGM IIUCOOLI REV 9; 

« CONVERT ; 

♦ TITLE IIU TCP WRITTEN IN A SHORT FORM DIALECT AND CONVERTED TO GOAL); 
a DATE I5JUL73I ; 

USE IMECHODELI; 

USE (TERMINALSI; 

DCL TXT CPUMPONI UMAX 2 CHRSS 

DCL QTY I STAGE INLET PRESS lU « STAGE INLET PRESS 21 ; 

DCL STA TAB « COOLING SYSTEM GN2 FILL ON SUITCHI 

W 1 R AND 3 CS 

TTL ION)t(OFF)f CAUTO) UE 

<M00 1815>f ON • OFF , OFF ; 

DCL STA TAB (WATER CONTROL VALVE CLOSED SUITCHI 

U 1 R AND 3 CS 

TTL (OPENIt KLDSEDIf (AUTQI WE 

<M00 1814>. OFF , ON * ON ; 

DCL STA TAB (lU COOLANT PUMP I ON SWITCH) 

W 1 R AND 3 CS 

TTL (ON)f (OFFItUUTOI UE 

<M00 lBl7>f ON • OFF » OFF ; 

OCL STA TAB 41U COOLANT PUMP 2 ON SWITCH) 

W 1 R AND 3 CS 

TTL (ONI » I OFF)* (AUTO) WE 

<M00 1358>» ON t OFF * OFF ; 

DCL STA TAB (PRESSURE SWITCH ACTIVATED SW) 

W 1 R AND 3 CS 

TTL (ON)*(OFF)tlAUTQl WE 

<MDO 1343>* ON * OFF , OFF ; 

OCL STA TAB UU COOLANT PUMP 1 AND 2 OFF SWITCH) 

W I R AND 3 CS 

TTL (ONI* (OFF)* (AUTO) WE 

<M00 1342>* ON * OFF . OFF ; 

OCL STA TAB (HIGH PRESSURE REGULATOR ON SW) 

W 2 RS AND 3 CS TTL 

(LOW)* (HIGH)* (AUTO) UE 
<M00 490>* OFF * ON * OFF * 

<M00 49I>, ON * OFF , OFF ; 

OSP TXT I.Y.THIS PROCEDURE MILL BRING THE) 

TXT (•Y^GROUND COOLING UNITS AND THE)* 

TXT (.Y-IU THERMAL CONDITIONING SYSTEM)* 

TXT C.Y.TO OPERATING CONDITION)* TO <CRT2-3>; 

STP; 

PER (GSCU POWER UP) REV 1; 

DSP TXT (.C. BEGIN lU PNEUMATIC PANEL PREPS)* 

TXT (.C.USE OIS CHANNEL 154)* 

TXT (•C^REPORT TO CUNP WHEN COMPLETE)* TO <CRT2-3>; 
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GOAL COMPILER SOURCE RECORD LISTING 


RECORD SOURCE RECORD 


51 

52 

53 
5A 
55 
5A 

57 

58 

59 

60 
61 
62 
63 
66 

65 

66 

67 

68 

69 

70 

71 

72 

73 

74 

75 

76 

77 

78 

79 

80 
81 
82 

83 

84 

85 

86 

87 

88 

89 

90 

91 

92 

93 

94 

95 

96 

97 

98 

99 
100 


t ON THE lU GROUND PNEUMATICS PANEL ; 

SllO RELEASE S 175S 

VFY <SYSTEM INLET PRESSURE GAilGE> IS 8TU 3300 PSIG AND 6000 PSIG 
ELSE DSP XCPS UR* GN2 SUPPLY NOT 3300 - 6000 PSIGI 
TO <CRT2-5> AND STP • SllO# S 115 ; 

SI 15 AVG 6 RO <STAGE INLET PRESSURE GAUGE> 

ASA I STAGE INLET PRESS II S 
S120 VFY <MAN|FOLO PRESSURE &AUGE> IS LT 100 PSIG 

ELSE DSP XCPS UR. MANIFOLD PRESSURE NOT L.T. 100 PSD 
TO <CRT2> AND STP # S120# S 130; 

SI30 SET IHIGH PRESSURE REGULATOR ON SN) FNS TO (LOUl; 

MTE 5 SECS; 

S140 VFY <HIGH PRESSURE REG ON LAMP> IS OFF ELSE DSP XCPS 

UR.HIGH PRESS REG ON LAMP IS NOT OFFI TO <CRT2> 

AND STP « S 140# S 150; 

$ IF MANIFOLD PRESSURE IS OUT OF TOLERANCE DO S 160; 

S15D VFY <MANIFOLO PRESSURE GAUGE> IS 6TM 1600 PSIG AND 1800 PSIG 
ELSE DSP XCPS 

f.R. MANIFOLD PRESS IS NOT 1700 4/-100) TO <CRT2-0> 

AND 6T0 $160; 

GTO S 180; 

S160 SET IHIGH PRESSURE REGULATOR ON SNI FNS TO lAUTOI; 

DLY 5 SECS; 

SET <REDUNDANT PRESS REG ON SW> TO ON; 

DSP TXT UG. redundant PRESS REG ON COMMANOI, 

TXT UG.HAS BEEN ISSUEDI# TO <CRT2> ; 

NTE 5 secs; 

VFY CREDUNOANT PRESS REG ON LAMP> IS ON ELSE DSP XCPS 
UR.REOUN PRESS REG LAMP IS NOT ONI TO <CRT2> 

AND STP # S 160# S 170 ; 

S170 AVG 3 RO <STAG£ INLET PRESSURE GAUGE> 

ASA I STAGE INLET PRESS 21; 

IF ISTAGE INLET PRESS II IS GEO 

I STAGE INLET PRESS 21 THEN GTO S 180; 

DSP TXT I. V. STAGE INLET PRESSURE INCREASEOI# 

TXT UY.Hl PRESS REG READING NASI ISTAGE INLET PRESS II# 

TXT I.Y*REOUN PRESS REG READING NASI (STAGE INLET PRESS 21# 
TO <CRT2-0> ; 

DSP TXT I.Y. PRESENT VALVE OF STAGE INLET PRESS)# 

TO <CRT2-10>; 

S175 EVY 3 SECS CNC PER PGM (STAGE GN2 INLET PRESS) REV l: 

STP f SllO# SIBO; 

S160 RLS S175 ; 
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GOAL COMPILER SOURCE RECORD LISTING 


RECORD 

SOURCE 

RECORD 




101 


SET 

<SUPPLY SYSTEM ON SW> TO ON; 




102 


DLY 

5 SECS; 




103 







104 


VFY 

<SUPPLY SYSTEM ON LAMP> IS ON ELSE DSP XCPS 




105 



I.R. SUPPLY SYSTEM ON LAMP IS NOT ONI 




106 



TO <CRT2-3> AND STP, SIRO, S190; 




107 

S190 

RLS 

S195; 




106 


VFY 

<STAGE INLET PRESSURE GAU6E> IS BTM 1600 PSIG 

AND 

1600 

PSIG 

109 



ELSE OSP XCPS 




110 



<.R. STAGE INLET PRESS NOT 1600-1800 PSIl 

TO 

<CRT2- 

9> 

111 



AND GTO S194; 




112 


GTO 

S 200; 




113 

S194 


DSP TXT UY. STAGE INLET PRESSURE!, 




114 



TO <CRT2-10>; 




115 

S195 

EVY 

3 SECS CNC PER PGM (STAGE GN2 INLET PRESS! REV 

i; 



116 


STP 

, S190. S200: 




117 

S200 

RIS 

S19S; 




116 


DSP 

TXT (.G.IU PNEUMATICS PANEL PREPS COMPLETE!* 




119 



TXT UG. NOTIFY CUNP ON OIS CHANNEL 154)» TO <CRT2 

-0>; 


120 


TRM; 





121 


END 

PGM; 
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GOAL COMPILER EXPANDED SOURCE STATEMENT LISTING 


STMT EXPANDED SOURCE STATEMENT 


1 BGN PGM (lUCOOL) REV 9: 

2 USE (MECMODELl: 

3 USE (TERMINALS); 

4 DECLARE TEXT (PUMPON) WITH A MAXIMUM OP 2 CHARACTERS: 

5 DECLARE QUANTITY (STAGE INLET PRESS 1), (STAGE INLET PRESS 2) : 


6 


7 


8 


9 


^3 10 

ro 


11 


12 


DECLARE STATE TABLE (COOLING SYSTEM GN2 FILL ON SWITCH) 

WITH 1 ROW AND 3 COLUMNS 

TITLED (ON), (OFF), (AUTO) WITH ENTRIES 
<MD0 181S>, ON , OFF , OFF i 
DECLARE STATE TABLE (WATER CONTROL VALVE CLOSED SWITCH) 

WITH 1 ROW AND 3 COLUMNS 

TITLED (OPEN), (CLOSED), (AUTO) WITH ENTRIES 

<MD0 ieiA>, OFF , ON , ON ; 

DECLARE STATE TABLE (lU COOLANT PUMP 1 ON SWITCH) 

WITH 1 ROW AND 3 COLUMNS 

TITLED (ON), (OFF), (AUTO) WITH ENTRIES 

<MDO 1817>, ON , OFF , OFF ; 

DECLARE STATE TABLE ( lU COOLANT PUMP 2 ON SWITCH) 

WITH 1 ROW AND 3 COLUMNS 

TITLED (ON), (OFF), (AUTO) WITH ENTRIES 

<MOO 1358>, ON , OFF , OFF ; 

DECLARE STATE TABLE (PRESSURE SWITCH ACTIVATED SW) 

WITH I ROW AND 3 COLUMNS 

TITLED (ON), (OFF), (AUTO) WITH ENTRIES 

<MD0 1343>, ON , OFF , OFF ; 

DECLARE STATE TABLE ( lU COOLANT PUMP 1 AND 2 OFF SWITCH) 

WITH 1 ROM AND 3 COLUMNS 

TITLED (ON), (OFF), (AUTO) WITH ENTRIES 

<M00 1342>, ON , OFF , OFF ; 

DECLARE state TABLE (HIGH PRESSURE REGULATOR ON SW) 

WITH 2 ROWS AND 3 COLUMNS TITLED 

(LOW), (HIGH), (AUTO) WITH ENTRIES 
<M00 490>, OFF , ON , OFF , 

<MDO 49l>, ON , OFF , OFF ; 
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TCP WRITTEN IN A SHORT FORM DIALECT AND CONVERTED TO GOAL 


5JUL73 


GOAL 01 


PAGE 


2 


GOAL COMPILER EXPANDED SOURCE STATEMENT LISTING 

STMT EXPANDED SOURCE STATEMENT 

( ********** BEGIN OPERATING STEPS ♦♦**••♦*** ; 

13 DISPLAY TEXT (.Y.THIS PROCEDURE MILL BRING THE) 

TEXT (.Y. GROUND COOLING UNITS AND THE ) » 

TEXT I.Y.IU THERMAL CONDITIONING SYSTEM), 

TEXT I.Y.TO OPERATING CONDITION), TO <CRT2-3>; 

lA STOP; 

15 perform (GSCU POWER UP) REVISION 1; 

16 DISPLAY TEXT I.C. BEGIN lU PNEUMATIC PANEL PREPS), 

TEXT (.C.USE OIS CHANNEL 154), 

TEXT (,C. REPORT TO CUNP WHEN COMPLETE), TO <CRT2-3>{ 

$ ON THE lU GROUND PNEUMATICS PANEL i 

17 STEPllO RELEASE STEP 175; 

18 VERIFY <SYSTEM INLET PRESSURE GAUGE> IS BETWEEN 3300 PSIG AND 6000 PSIG 

ELSE DISPLAY EXCEPTIONS I.R. GN2 SUPPLY NOT 3300 - 6000 PSIG) 

TO <CRT2-5> AND STOP AND INDICATE RESTART LABELS STEPllO, STEP 115 ; 

19 STEP115 AVERAGE 6 READINGS OF <STAGE INLET PRESSURE GAUGE> 

AND SAVE AS (STAGE INLET PRESS 1) ; 

20 STEP120 verify <MANIF0LD PRESSURE GAUGE> IS LESS THAN 100 PSIG 

ELSE DISPLAY EXCEPTIONS I.R. MANIFOLD PRESSURE NOT L.T. 100 PSD 
TO <CRT2> AND STOP AND INDICATE RESTART LABELS STEP120, STEP 130; 

21 STEP130 SET (HIGH PRESSURE REGULATOR ON SW) FUNCTIONS TO (LOW); 

22 WAIT 5 secs; 

23 STEP140 VERIFY <HI6H PRESSURE REG ON LAMP> IS OFF ELSE DISPLAY EXCEPTIONS 

I.R.HIGH PRESS REG ON LAMP IS NOT OFF) TO <CRT2> 

AND STOP AND INDICATE RESTART LABELS STEP 140, STEP 150; 

> IF MANIFOLD PRESSURE IS OUT OF TOLERANCE DO S 160; 

24 STEP150 VERIFY <MANIFOLO PRESSURE GAUGE> IS BETWEEN 1600 PSIG AND 1800 PSIG 

ELSE DISPLAY EXCEPTIONS 

(.R. MANIFOLD PRESS IS NOT 1700 ♦/-lOO) TO <CRT2-0> 

AND GO TO STEP160; 

25 GO TO STEP 180; 

26 STEP160 SET (HIGH PRESSURE REGULATOR ON SW) FUNCTIONS TO (AUTO); 

27 DELAY 5 SECS; 

28 SET <REOUNOANT PRESS REG ON SW> TO ON; 

29 DISPLAY TEXT ( ,G. REDUNDANT PRESS REG ON COMMAND), 

TEXT (.G.HAS BEEN ISSUED), TO <CRT2> ; 

30 WAIT 5 SECS; 

31 VERIFY <REDUNDANT PRESS REG ON LAMP> IS ON ELSE DISPLAY EXCEPTIONS 

(.R.REDUN PRESS REG LAMP IS NOT ON) TO <CRT2> 

AND STOP AND INDICATE RESTART LABELS STEP 160, STEP 170 ; 

32 STEP170 AVERAGE 3 READINGS OF <STAGE INLET PRESSURE GAUGE> 
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GOAL COMPILER EXPANDED SOURCE STATEMENT LISTING 


STMT EXPANDED SOURCE STATEMENT 

AND SAVE AS I STAGE INLET PRESS 2)5 

33 IF (STAGE INLET PRESS 1) IS GREATER THAN OR EQUAL TO 

(STAGE INLET PRESS 21 THEN CO TO STEP 180; 

34 DISPLAY TEXT I.Y, STAGE INLET PRESSURE INCREASED! t 

TEXT (.Y.HI PRESS REG READING HAS) (STAGE INLET PRESS 1). 

TEXT (.Y.REOUN PRESS REG READING HAS) (STAGE INLET PRESS 2)» 

TO <CRT2-0> ; 

35 DISPLAY TEXT (.Y. PRESENT VALVE OF STAGE INLET PRESS), 

TO <CRT2-10>: 

36 STEP175 EVERY 3 SECS CONCURRENTLY PERFORM PROGRAM (STAGE GN2 INLET PRESS) REVISION 1: 

37 STOP AND INDICATE RESTART LABELS STEPllO, STEP180; 

38 STEP180 RELEASE STEP175 ; 

39 SET <SUPPLY SYSTEM ON SH> TO ON; 

40 DELAY 5 SECS; 

‘tl VERIFY <SUPPLY SYSTEM ON LAMP> IS ON ELSE DISPLAY EXCEPTIONS 

(.R. SUPPLY system ON LAMP IS NOT ON) 

TO <CRT2-3> AND STOP AND INDICATE RESTART LABELS STEP180, STEP190; 

42 STEP190 release STEP195; 

43 VERIFY <STAG6 INLET PRESSURE GAUGE> IS BETHEEN 1600 PSIG AND 1800 PSIG 

ELSE DISPLAY EXCEPTIONS 

(»R. STAGE INLET PRESS NOT 1600-1800 PSD TO <CRT2-9> 

AND 60 TO STEP194; 

44 GO TO STEP 200; 

45 STEP194 DISPLAY TEXT I. Y. STAGE INLET PRESSURE), 

TO <CRT2-10>; 

46 STEP195 EVERY 3 SECS CONCURRENTLY PERFORM PROGRAM (STAGE GN2 INLET PRESS) REVISION 1; 

47 STOP AND INDICATE RESTART LABELS STEP190, STEP200; 

48 STEP200 RELEASE STEP195; 

A9 DISPLAY TEXT (.G.IU PNEUMATICS PANEL PREPS COMPLETE), 

TEXT I.G.NOTIFY CUNP ON OIS CHANNEL 154), TO <CRT2-0>; 

50 TERMINATE; 

51 END PROGRAM; 
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INTERNAL NAME CROSS-REFERENCE LISTING 


INTERNAL NAME 

TYPE 

SIZE 

DEFINED AT 


REFERENCED AT 

lAUTOl 

COLUMN 

«POWS 

0006 

0026 


(CLOSED) 

COLUMN 

«ROWS 

0007 


UNREFERENCED 

** 

(C00LINGSTSTEHGN2FILL0NSWITCH) 

STATE 

01X03 

0006 


UNREFERENCED 


(HIGHPRESSUREREGULATORONSW) 

STATE 

02X03 

0012 

0021 0026 


(HIGH) 

COLUMN 

»ROUS 

0012 

** 

UNREFERENCED 

♦ ♦ 

( lUCQOLANTPUHPlANOaOFFSHITCH) 

STATE 

01X03 

0011 


UNREFERENCED 

** 

( lUCOOLANTPUHPlONSHITCH) 

STATE 

01X03 

0008 


UNREFERENCED 


( 1UCOOLANTPUMP2QNSMITCH) 

STATE 

01X03 

0009 


UNREFERENCED 


(LOW) 

COLUMN 

ARONS 

0012 

0021 


(OFF) 

COLUMN 

ARQWS 

0006 


UNREFERENCED 


(ON) 

COLUMN 

ARONS 

0006 


UNREFERENCED 

♦♦ 

(OPEN) 

COLUMN 

ARONS 

0007 


UNREFERENCED 


( PRESSURE SU I TCHACTIVATEDSW) 

STATE 

01X03 

0010 


UNREFERENCED 


(PU)(PON) 

TEXT 

00001 

0006 


UNREFERENCED 


(STACEINLETPRESSl) 

QUANTITY 

OOOOl 

0005 

0019 0033 0034 


(STAGEINLETPRESS2) 

QUANTITY 

00001 

0005 

0032 0033 0034 


(WATERCONTROLVALVECLQSEDSHirCH) 

STATE 

01X03 

0007 


UNREFERENCED 
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STATEMENT LABEL CROSS-AEEERENCE LISTING 


LABEL 

DEFINED AT 

REFERENCED AT 

S QUO 

0017 

0018 0037 

$ 011$ 

0019 

0018 

S 0120 

0020 

0020 

S 0130 

0021 

0020 

S 0140 

0023 

0023 

s oiso 

0024 

0023 

S 0160 

0026 

0024 0031 

S OITO 

0032 

0031 

S 017$ 

0036 

0017 0038 

$ 0180 

0038 

0025 0033 0037 0041 

S 0190 

0042 

0041 0047 

S 0194 

0045 

0043 

S 0195 

0046 

0042 0048 

S 0200 

0046 

0044 0047 


RAGE 1 
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FUNCTION DESIGNATOR CROSS-REFERENCE LISTING 

DATA BANK NAME DATA BANK NUMBER 

(MECMODELI 0001 

< TERM INALS I 0002 
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GOAL 01 


FUNCTION DESIGNATOR 


<CRT2> 

<CRT2-0> 

<CRT2-10> 

<CRT2-3> 

<CRT2-5> 

<CRT2-9> 

<MIGHPRESSUReRE60NLANi»> 
<HAN| F0L0PRESSUREGAU6E> 
<N0013A2> 

<N0013A3> 

<M00135B> 

<N00ieiA> 

<HD0iei5> 

<N00U17> 

<H00490> 

<N00A91> 

<REDUNDANTPRESSREGONLAMP> 

<REDUNOANTPRESSREGONSU> 

<stageinletpressuregauge> 

<SUPPLYSYSTENONLANP> 

<SUPPLYSYSTEN0NSW> 

<SYSTEN1NLETPRESSUREGAUGE> 


ro 

I 

ro 


FUNCTION DESIGNATOR CROSS-REFERENCE LISTING 

AODRS DATA 6NK REFERENCED AT 


SYSTEH i/Q 00002 
SYSTEM I/O 00200 
SYSTEM I/O 00210 
SYSTEM I/O 00203 
SYSTEM I/O 00205 
SYSTEM I/O 00209 
SENSOR DISCRETE 00292 
SENSOR ANALOG 00123 
LOAD DISCRETE 00904 
LOAD DISCRETE 00892 
LOAD DISCRETE 00902 
LOAD DISCRETE 00860 
LOAD DISCRETE 00916 
LOAD DISCRETE 00900 
LOAD DISCRETE 00320 
LOAD DISCRETE 00248 
sensor DISCRETE 00087 
LOAD DISCRETE 00602 
SENSOR ANALOG 00148 
SENSOR DISCRETE 00028 
LOAD DISCRETE 00572 
SENSOR ANALOG 00111 


0002 

0020 

0023 

0029 0031 

0002 

0024 

0034 

0049 

0002 

OOJ5 

004S 


0002 

oou 

0016 

0041 

0002 

0018 



0002 

0043 



0001 

0023 



0001 

0020 

0024 


0001 

0011 



0001 

0010 



0001 

0009 



0001 

0007 



0001 

0006 



0001 

0000 



0001 

0012 



0001 

0012 



0001 

0031 



0001 

0028 



0001 

0019 

0032 

0043 

0001 

0041 



0001 

0039 



0001 

0018 
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GOAL COMPILER DIAGNOSTIC SUMMARY 


WARNINGS. 


THE FOLLOWING INTERNAL NAMES HERE UNREFERENCED : 


(CLOSED) 

( IUC00LANTPUMP1AN020FFSW1TCH) 
(OFF) 

(PRESSURESWITCHACTIVATEDSW) 


(COOLINCSYSTENGN2FILLONSMITCH) 
( lUCOQLANTPUMPlONSHITCH) 

(ONI 

(PUMPON) 


END OF DIAGNOSTICS. 


total number of SOURCE RECORDS: 121 

TOTAL NUMBER OF STATEMENTS: SI 

TOTAL NUMBER OF WARNINGS: 12 

TOTAL NUMBER OF ERRORS : 0 

HIGHEST CONDITION CODE HAS A 


(HIGH) 

( I UCOOLANTPUHP20NSH I TCH > 

(OPEN) 

(HATERCONTRDLVALVECLOSEDSWITCH) 
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SECTION 3.0 

ENGINEERING UNITS TECHNIQUES 


T 



3.1 PURPOSE OF DOCUMENT 

This document represents an effort to define the future role of 
engineering units in the GOAL language. The advantages and disad- 
vantages win be discussed and the necessary ground rules and 
conventions will be identified. 

3.1.1 Role of Engineering Units 

The present use of engineering units is for readability only. No 
attempt has been made to automatically scale units or check for proper 
dimensional operations. As to the future of engineering unitSi this 
document will identify a recommended system of engineering units and 
evaluate methods for incorporating the required processing techniques 
into the GOAL Compiler. Items that affect an Operating System will 
also be identified. 

3.1.2 Advantages 

There are several advantages to be gained by incorporating engineering 
units into the GOAL System. The major advantages are associated with 
readability, automatic unit scaling, and usage validation. Other benefits 
include validation of subroutine parameters, and the validation of console 
Inputs to the on-line system. 

3.1.3 Disadvantages 

In order for engineering units to be properly scaled and validated, 
additional restrictions must be imposed on the procedure writer. To 
ensure clear and unambiguous meaning of GOAL statements using units, 
comprehensive and rigorous tests must be made by the compiler. Once 
a procedure writer has decided to use engineering units, he must con- 
tinue using them to the completion of the procedure. 

3.1.4 Ground Rules 

This document will identify the conventions and guidelines required to 
implement engineering units in the GOAL Language. Problem areas related 
to this effort will be discussed. 

3.2 TECHNICAL APPROACH 

The analysis of engineering units techniques in the GOAL Language will 
be presented according to the following outline: 

3.2.1 System of Units 

A candidate set of engineering units is provided to support operations 
involving electrical, mechanical, and thermal terminology. This set is 

identified in Table 3-1, It is described in further detail in Section 
3.3. 
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3.2.2 


Compiler and Operating System Ground Rules 

The use of engineering units is discussed for the various GOAL Language 
Statements in which they occur. Assumptions regarding real time operations 
are described. This analysis is given in Section 3,7, 

3.2.3 Potential Problem Areas 

Problem Areas related to the use of engineering units in the GOAL Language 
are described in Section 3.12. 

3.2.4 Implementation Techniques 

A phased approach for implementation of engineering units with the GOAL 
Compiler is given in Section 3.13. 

3.3 SYSTEM OF UNITS 

3.3.1 Conventional Systems 

The conventional systems, English and Metric, are discussed and a technique 
is described for conversion to an internal working unit system. 

3.3.2 English Systems and Metric Systems Unit Definitions 

In any logical system of units it is necessary at the beginning to assume 
certain units artitrarily. In each of the commonly used systems there 
are three fundamental units. The fundamental quantities in the inter- 
national scientific system are length, mass, and time. In the English 
system the fundamental quantities are length, force, and time. A com- 
parison of two forms of the scientific system and one of the English 
system is as follows: 


Quanti ty 

MKS 

System 

CGS 

System 

ENGLISH (f Ibm s) 
Sys tern 

Length 

Meter 

Centimeter 

Foot 

Mass 

Kilogram 

Gram 

Lb Mass 

Density 

O 

Kilogram/Meter 

Gram/ Centimeter^ 

Lb Mass/Foot^ 

Force 

Newton 

Dyne 

Poundal 

Work (energy) 

Joule 

Erg 

Foot Poundal 

Power 

Watt 

Erg/Sec 

Poundal /Sec 

Time 

Second 

Second 

Second 



As shown In the table the differences between the three systems, other 
than the assumption of the arbitrary units, is the choice of the funda- 
mental quantities. In CGS and MKS the unit of mass is a fundamental 
unit while that of force is a derived one. 

3.3.3 Conversion Techniques 

A variable expressed in the units of one system can be converted to 
equivalent units in another system. The conversion is accomplished by 
using a constant relationship between the two systems as a multiplier 
or divisor. Using the MKS system as a baseline, the conversion constants 


for the CGS and 

f Ibm s systems are 

1 as follows: 


Quantity 

MKS 

CGS 

f Ibm s 

Length 

1 Meter 

10^ CM 

3.281 ft 

Mass 

1 Kilogram 

10^ Gram 

2.205 Ibm 

Densi ty 

1 K/M^ 

10"^ GM/cm3 

62.43x10“^ lbm/ft3 

Force 

1 Newton 

10^ dyne 

7.015 poundal 

Work (Energy) 

1 Joule 

10^ erg 

23.02 ft poundal 

Power 

1 Watt 

10^ erg/sec 

23.02 ft poundal /sec 

A simple conversion example using 

the quantity length is 

as follows: 


Convert 6 feet to meters 


6 feet = 6 feet 3.281 feet/meter = 1.829 meters 

The conversion technique can be easily applied to convert units from 
various systems to units of a single system. 

3.4 SPECIALIZED SYSTEMS 

The principal system units discussed thus far have been those of the 
Mechanical System. This section will include those units associated 
with the Electrical and Thermal Systems. 

3.4.1 Electrical Systems 

There are eight or ten different systems of electrical and magnetic units 
which are in common use. Each system is based on a choice of a constant 
of proportionality in an experimentally verified physical law. For the 
purpose of this paper we will limit our discussion to three of the more 
common systems. The CGS electrostatic system (esu) units are derived 
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from Coulomb's law which says that the force, f, between two electrical 
charges, qi and q?» separated by a distance r in empty space is directly 
proportional to tne product of the charges and inversely proportional to 
the square of the distance between them. 

f = K q^ q2/r2 

where K is a constant chosen as unity and dimensionless. 

The CGS electromagnetic system (emu) units are derived from the law of 
attraction between currents. If two currents of magnitude I] and Ip 
flow in long parallel wires, separated by a distance d, they attract 
each other with a force per unit length given by 

f = K I^ 12 /d 

where K is a constant chosen as 2 and dimensionless. 

The two systems discussed thus far have used CGS mechanical units. By 
using MKS mechanical units, we are able to define a system of units that 
coincide closely with the practical system of units which grew up in the 
nineteenth century. The volt, ampere, henry, farad, and ohm are all units 
of the MKS system. 

Using the MKS system of electrical units as a baseline, the conversion 
constants and the units associated with each are illustrated in the 
following table; 


Quantity 

MKS 

esu electrostatic 

emu electromagnetic 

Charge 

1 Coulomb 

2.998x10^ Statcoulomb 

.1 Ab coulomb 

Potential 

Difference 

1 Volt 

3.336x10'^ Statvolt 

108 Abvolt 

Current 

1 Ampere 

2.998x10® Statampere 

.1 Abampere 

Resistance 

1 Ohm 

1.1126x10"^^ Statohm 

10 ® Abohm 

Power 

1 Watt 

10 ^ erg/sec 

10 ^ erg/sec 

Inductance 

1 Henry 

1.1 126x10“ Stathenry 

10 ^ cm 

Capacitance 

1 Farad 

8.988x10^^ cm 

lQ-9 Abfarad 


3.4.2 Mechanical Systems 

The mechanical units have been discussed previously. (See the table 
of MKS, CGS, and English units in Section 3.3.3. 
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3.4.3 


Thermal Systems 


Thermal measurements involve the specification of temperature. Two 
temperature scales are in common use and both are defined in terms 
of measurements made with a mercury thermometer and both having the 
freezing and boiling point of pure water at standard atmospheric 
pressure as the fixed points. The Centigrade scale uses 0® and 100° 
while the Fahrenheit scale uses 32° and 212°, The scales are extended 
by the Kelvin or Absolute temperature scale and the Rankine temperature 
scale. The Kelvin scale is independent of the properties of any partic- 
ular substance except that the difference between the boiling and freezing 
point of water will be 100°K. The Zero value is the lowest limit temper- 
ature that can be approached but never reached. The Rankine scale 
corresponds to the Kelvin scale, but is based on absolute zero of the 
Fahrenheit system. Using the MKS °C System as the baseline, the relation- 
ships among thermal units are as follows; 


Quantity 

MKS °C 

MKS °K CGS°K 

f Ibms °F 

f Ibms °R 

(Temperature 

Difference) 

i°c 

o 

o 

1 .80°F 

1.80°R 

Temperature 

x°c 

(273. 16+X)°K (273. 16+X)° F(32+9X/5)°F 

(491.7+9X/5)°F 

Energy 

1 joule 

1 joule lO^erg 

9.478X10-4 BTU 

9.478X10"^ BTU 


3.4.4 Compatibility Between Systems 

Compatibility between units of the same systems (Mechanical, Electrical, 
and Thermal), can be maintained if the units are scaled to a common 
internal working unit base. Working units will be discussed in Section 3.6. 

3.5 AMBIGUITIES 

Ambiguities can be created by the use of engineering units if the units 
are used only part of the time, if they are used incorrectly, or if the 
user doesn't know what internal working units are being used. 

Ambiguities can also be created by the order in which arithmetic opera- 
tions are performed. This problem will be discussed in greater detail 
in Section 3.12 (Potential Problem Areas) 

3.5.1 Mass vs. Force Conventions 

This ambiguity arises in the specification of Mass or Force in the English 
system of units. If the pound unit is used a compiler will not be able to 
determine if it is pounds force or pounds mass. 
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Specific engineering unit symbols will have to be defined for mass 
and force units in order to provide the GOAL procedure writer with 
meaningful results. 

3.5.2 On, Closed, True vs. Off, Open, False 

These operators have been discussed at great length and it is generally 
agreed that the ambiguity is created by the Mechanical/Electrical System 
definitions. As with force and mass a convention must be established 
regarding their use. 

3.5.3 Absolute vs. Relative Temperature and Pressure 

The Thermal System units involve, in addition to the mechanical fundamental 
quantities of mass, length, and time (m, 1, and t), the specification of 
temperature ( 0 ). The present list of engineering units in the Syntax 
diagram handbook contains the capability for relative or absolute pressure, 
but does not have the capability for temperature expression. Absolute 
measurements are with respect to the null condition, while relative 
measurements are expressed as the difference between two limits, (i.e., 
lOO^A absolute is very cold, 100 A° relative is the difference between 
the freezing and boiling point of water). Additional units will have 
to be defined for the representation of Absolute and Relative temperature 
if they are to be included in the list of legal Engineering units. 

3.6 WORKING UNITS 

If the GOAL System is to provide the Procedure Writers with the capability 
to use different engineering units within the same statement, all units 
will have to be converted to a common denominator. This suggests the use 
of a system of internal working units. In selecting a set of internal 
working units it is highly desirable that the system consists of units 
that are common to Mechanical, Electrical, or Thermal Systems, and are 
of sufficient size to handle both large and small units. The system that 
seems best suited to meet this criteria is the MKS system. This system 
is larger than the CGS system and is about the same size as the English 
System. There is a distinct advantage in the electrical system units in 
the MKS system. Nearly all of these quantities evolved during the nine- 
teenth century and units such as the volt, ampere, henry, farad, and ohm 
are already in the MKS system. The MKS is already the standard system 
in most all but the English speaking countries today. Some of these 
countries are converting to the metric system and others are studying the 
problem. This seems to be the logical system of internal working units 
for the GOAL System. The procedure writers should be free to use any 
system of units that they desire, but if automatic scaling of units and 
usage validation are to be included in the GOAL System, it is recommended 
that the MKS system units be adopted as the Internal working unit. 
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3.7 COMPILER AND OPERATING SYSTEM GROUND RULES 

This section identifies the various ways that engineering units can be 
used in the GOAL statements. 

3.7.1 Quantity Declaratives 

These statements are used to identify specific internal names as quantity 
variables for the GOAL Compiler. The quantity declaration will enable the 
compiler to validate all statements that use the variable. 

3. 7. 1.1 Initialized Quantity Variables 

When a quantity variable is declared it may be assigned initial values. 
These are expressed as a numeric value followed by some engineering units. 
These units are used to determine the conversion required to obtain the 
initial values in the MKS internal working system. 

3. 7. 1.2 Uninitialized Quantity Variables 

If a quantity variable is not assigned an initial value it may still be 
given engineering units which will be used to validate its usage. In 
this case the numeric value is omitted in the DECLARE statement. This 
will enable the compiler to validate the statements that use the variable. 

3. 7. 1.3 Dimensionless Quantities 

If a quantity variable is not assigned engineering units, it is considered 
to be a dimensionless quantity and it is assigned 'null' units. 

These special quantities will be discussed in Section 3.12. 

3.8 ARITHMETICAL EXPRESSIONS 

3.8.1 Balanced Dimensions 

Arithmetic operations must be performed using engineering units with 
compatible dimensions. It must be legal to perform arithmetic oper- 
ations with all types of units; however, the resulting units must be 
equal to the declared quantity units for the variable to the left of 
the expression. For expressions that perform either addition or sub- 
traction it is a simple matter to verify that the dimensions are the 
same. For example, it is legal to add or subtract units whose fundamental 
quantities of length, mass, or time (1, m, t) are identical. The problem 
occurs when multiplication and division are performed within an expression. 
These two arithmetical operations create composite units. 

3.8.2 Composite Units 

When unlike units are multiplied or divided the resulting composite units 
may or may not be legal units. The creation of composite units will depend 
upon the order in which arithmetical expressions are evaluated. This 
problem will be discussed in Section 3.12. 
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3.9 


COMPARISON TESTS 


3.9.1 Compatible Comparands 

All comparison tests should be performed on like conparands. This is a 
continuation of the current GOAL compiler rule that unlike Function 
Designators cannot be used in comparison tests. Quantity variables used 
in comparison tests will have to have the same fundamental quantities, 
but not necessarily the same units. For example, it should be legal to 
compare inches to feet because the same fundamental quantity, length (1) 
is common to both variables. 

3.9.2 Required Scaling 

If internal working units are in a canmon system such as MKS, then the 
GOAL Compiler and online executive system can perform the required scaling 
for quantity variables. If variables, other than quantities, are used for 
comparison tests or I/O operations, the procedure writer will be respon- 
sible for proper scaling. 

3.10 ANALOG I/O 

3.10.1 Calibration and Scaling 

If the engineering unit theme is to be followed throughout the GOAL system, 
analog values should be automatically scaled for I/O operations. In order 
to convert the analog value to the proper value, the executive system must 
have access to the calibration data for measurements and the engineering 
unit identifiers for each measurement. With this data, the programs could 
use actual units rather than 0-5 volts or some other scale. 

3.11 KEYBOARD AND DISPLAY I/O 

3.11.1 Validation and Scaling 

Keyboard input can be validated by checking engineering units specified 
for input parameters. If the GOAL procedure is expecting Volts for input 
the units can be tested and scaled before the parameter is passed to the 

program. Output can be handled in the same way except that the units 

could be optional. If no units were specified, the executive could scale 
to the MKS unit and output the data. If units were specified, the units 
will be converted to that specified. 

3.12 POTENTIAL PROBLEM AREAS 

3.12.1 Special Quantities 

Special consideration will have to be made for dimensionless quantities. 
Items such as specific gravity, specific heat, n, e and others which may 
require special unit designations when automatic scaling and usage vali- 
dation are to be performed. The potential problem area is associated. 



with mixing numeric data or constants with declared quantities. The 
compiler will be unable to verify arithmetic expressions if there are 
no restrictions placed upon the variables allowed In the expressions. 

3.12.2 Composite Units 

Composite units maybe generated during the evaluation of arithmetic 
expressions or when arithmetic calculations are performed over the 
course of several GOAL statements. The composite units which are gener- 
ated during the course of evaluation of an arithmetic expression may be 
the most difficult to implement. These operations will be dependent 
upon the order of variables as coded by the procedure writer. The entire 
expression may have to be evaluated and the resulting units compared to 
the defined units for the variable to the left of the expression. 

A method will have to be Identified which will allow a GOAL Procedure 
writer to identify units which are not Included in the accepted list 
of engineering units. A suggested method for defining composite units 
is shown in Table 3-3. 

3.12.3 Temporary storage of Data 

Temporary storage of data should not cause any problems with engineering 
units since all variables must be declared. The GOAL Procedure writer 
will have to be aware of the problems identified with composite units 
when temporary storage locations are defined. 

3.12.4 Resolution and Precision 

By examination of conversion factor tables for conversion from other 
systems to the MKS system, six fractional decimal places should be 
sufficient for units which are expressed in "micro" units. The degree 
of accurary will probably be determined by the computer word size on 
which the GOAL system is implemented. Six fractional decimal places 
should be the smallest number considered. The number of integer digits 
required must be capable of supporting the "mega" unit. This requires 
at least 6 digits plus the significant digits. This would imply a 
minimum of 9 or 10 digits to the left of the decimal. These require- 
ments are within the capabilities of the floating point registers of 
many of the larger computer systems. 

3.13 IMPLEMENTATION TECHNIQUES 

3.13.1 Basic Methods 

The GOAL Compiler as it exists at the present time is considered the 
basic system. The engineering units listed in the GOAL Syntax Diagram 
Handbook may be used to enhance the readability of a GOAL Procedure. 

A cursory validation is performed by the Compiler to insure that the 
engineering units used are defined. If an engineering unit is not 
defined in the GOAL Compiler, it will be flagged as an error. The basic 
method consists of a definition of all legal engineering units, but 
values are not scaled to compatible units and operations are not 
validated. 
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3.13.2 Automatic Scaling 

Automatic scaling of units to internal working units is the next suggested 
step for the implementation of engineering units. The internal working 
unit system recommended in Section 3.6 is the MKS System. In addition to 
recognizing the various types of engineering units as is presently done in 
the basic system the quantities will be scaled up or down in order to cor- 
respond to MKS Units. This operation will be performed during compilation, 
but the on-line system would have to recognize that all units were MKS. No 
validating of operations would be performed and it would be possible to add 
volts to amps and get PSI for a result. 

3.13.3 Dimensional Validation 

The third phase of implementation is a continuation of Phase Two. Auto- 
matic scaling would be performed as suggested in Section 3.13.2. In addition, 
unit usage will be validated by the compiler. 

A usage validation technique can be implemented using three fundamental 
quantities previously identified, length, mass, and time (1, m, t). The 
three fundamental quantities would be sufficient if either the mechanical 
or electrical systems were to be Implemented separately; however, some of 
the fundamental quantities are identical in the two systems. If we consider 
the permeability of a vacuum, v, as a fourth fundamental quantity in the 
electrical system, we can then distinguish between the mechanical and 
electrical systems. There is one other dimension in the thermal system 
which is variable and that is temperature, 0 . 

If the five defined fundamental quantities are used to define each engi- 
neering unit in the GOAL system, all arithmetic operations can be 
validated by addition, subtraction, or comparison of the subscripts of 
the fundamental quantities. The operations would be performed according 
to the following rules: 

1. Addition/Subtraction - the values of the subscripts of the five 
fundamental quantities must be identical for the operation to be legal. 

2. Multiplication - the values of the five fundamental quantities 
subscripts of the multiplier will be added to those of the multiplicand 
to form the subscripts of the product"! THe resulting five fundamental 
quantity values of the product must be identical to those of one of the 
engineering units defined in the GOAL system. 

3. Division - the values of the five fundamental quantity sub- 
scripts of the divisor will be subtracted from those of the dividend 
to form the subscripts of the quotient. The resulting fundamental 
quantity values of the quotient must be identical to those of one 

of the engineering units defined in the GOAL System. 
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With these rules, the user must be aware of the sequence of multiple 
operations. Intermediate units may be required for operations that 
are performed over several statements. 

The validation can be performed by reducing the operations to a Polish 
notation string and performing the indicated operations on the fundamen- 
tal quantity vectors during the compilation phase. Inconsistencies can 
be detected at this time. Table 3-2 contains the GOAL Engineering units 
expressed as the five fundamental quantities. Table 3-3 contains 
examples of unit validation using this technique. 
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3-12 


ENGINEERING UNITS 


FUNCTION 

TYPE 

VOLT 

CURRENT 

FREQUENCY 

RESISTANCE 

INDUCTANCE 

CAPACITANCE 

POWER 

PRESSURE 


DISTANCE 


BASIC 

UNIT 

XI 0^ 

XIO^ 

XI 0"^ 

XI 0‘® 

VOLT 

KILOVOLT 

MEGAVOLT 

MILLIVOLT 

MICROVOLT 

AMPERE 



MILLIAMP 

MICROAMP 

HERTZ 

KILOHERTZ 

MEGAHERTZ 



OHM 

KILOHM 

MEGAOHM 



henry 



Millihenry 

Microhenry 

farad 




Mi crof arad 

WATT 

KILOWATT 


Milliwatt 

Mi crowatt 


Ibs/in^ 
millibars 
in of Hg 

millimeters of Hg 

inch 

foot 

meter kilometer megameter millimeter micrometer 


nautical mile 


TABLE 3-1 
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ENGINEERING UNITS 


FUNCTION BASIC , 

TYPE UNIT XIO'^ XIO® XlQ-3 X10‘® 

VELOCITY feet/sec 

meters/sec 
knot 

mach. no. 

ANGLE degree 

arc min 
arc sec 
radi an 
revolution 

TEMPERATURE degrees centigrade 

degrees Fahrenheit 
degrees kelvin 


MASS 


kilogram 

slug 


gram 


TABLE 3-1 (Continued) 



3-14 


ENGINEERING UNITS 


FUNCTION 

TYPE 

DENSITY 

FORCE 

WORK 


BASIC , r. 

UNIT XIO-^ XIO^ 

K/m3 

Slug/ft^ 

Newton 

poundal 

Joule 


XlO-3 X10“® 

gm/cm^ 


O 

O 

=3 

r+ 


n> 

CL 


TABLE 3-1 



TABLE 3-2 


DIMENSIONAL FORMULAE 

The dimensional formulae are represented by the three fundamental 
quantities, length, mass, and time (1, m, t) plus the two additional 
defined quantities temperature (e) and the dielectric constant of a 
vacuum (y). 


Unit Name 
LENGTH 
MASS 
TIME 

TEMPERATURE 

AREA 

VOLUME 

VELOCITY 

ACCELERATION 

DENSITY 

FLOW 

FORCE 

PRESSURE 

WORK and ENERGY 

POWER (WATTS) 

VISCOSITY 

KINEMATIC VISCOSITY 
SURFACE TENSION 
ROTARY POWER 


Equivalent Units 
1 
m 
t 
e 

l2 

1 ^ 

lt“l 

lt“2 

ml“3 

l3t-l 

mlt‘2 

ml-it-2 

ml2f2 

ml2t-3 

ml"H“^ 

l2fl 

mt"2 

1-1 
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TABLE 3-2 (Continued) 


Unit Name 

Equivalent Unit 

QUANTITY OR CHARGE 

j,-l/2„,l/2^1/2 

CURRENT 

y-l/2ml/2il/2t-l 

POTENTIAL 

yl/2ml/2l3/2t-2 

RESISTANCE 

ylt“l 

VOLUME RESISTIVITY 

ul2t-l 

MASS RESISTIVITY 

)jml~^t~^ 

VOLUME CONDUCTIVITY 

u-h-h 

MASS CONDUCTIVITY 

u“ ^m"^l t 

CAPACITANCE 


INDUCTANCE 

jii 

THERMOELECTRIC POWER 

pl/V/2l3/2t-2e-l 

FLUX OF MAGNETIC INDUCTION 

^l/2^1/2i3/2t-l 

MAGNETIC FIELD INTENSITY 

,-l/2^1/2,-l/2t~l 

MAGNETIC POTENTIAL 

u-l/2^1/2il/2t-l 

RELUCTANCE 

u-ll-l 

MAGNETIC INDUCTION 

^l/2ml/2i-l/2t-l 
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TABLE 3-3 
EXAMPLE FORMULAE 


PRESSURE 

ml-U-2 


FORCE 4 AREA 
- 1^ 
ml-U-2 


POWER 

i2* "3 
m1 t 


CURRENT X POTENTIAL 
,l/2„,l/2i3/2t-2 + ,-V2ml/2il/2t-l 


VELOCITY 

H-1 


DISTANCE 4 TIME 
1 - t 


AREA 

l2 


LENGTH X WIDTH 
1 + 1 


DENSITY (mT^) 


COMPOSITE UNIT EXAMPLE 

= MASS (m) 4 VOLUME (1^) 


COMPOSITE (ml-2) MASS (m) 4 AREA (1^) 

DENSITY (ml -2) = COMPOSITE (ml -2) - HEIGHT (1) 
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TABLE 3-3 (Continued) 


1 

1 QUANTITY 

L 


COMPOSITE UNIT DEFINITION SYNTAX DIAGRAM 

r-' 1 



P “HA combination of the fundamental quantities 
I UNIT I 

j DEFINITION V. t, e and u) that describe the engineering 

\ unit being defined. 
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SECTION 4.0 


SUBROUTINE PARAMETER VALIDATION 



4.1 PURPOSE OF DOCUMENT 

This report will identify the role of the subroutine in the GOAL language. 
Off-line validation of system subroutine calling sequence will be discussed, 
and real time error conditions will be identified. 

4.2 TECHNICAL APPROACH 

Validation criteria will be established which will identify the require- 
ments for various operations associated with the subroutine. Validation 
procedures will be defined for the subroutine writer, the subroutine user, 
and for the group responsible for the system data bank. Implementation 
techniques will be discussed for the GOAL Compiler System Data Bank and 
On-line Operations. 

4.3 VALIDATION CRITERIA 

4.3.1 Compilation Time 

During the compile of a GOAL subroutine call, the subroutine revision 
level should be verified, the number and type of parameters certified 
and in some instances parameter values should be tested for limits. 

4.3.2 Execution Time 

Some error conditions can be anticipated, but nothing can be done by the 
off-line system to prevent them from occurring. This type of error is 
possible because some parameters will be calculated during execution of 
a GOAL program and the only way to find the problem is to execute the 
program. 

Error recovery from real time error conditions can be accomplished 
several different ways. Present day operating systems handle the real 
time error in one of two ways. The program and all steps associated 
with the program are terminated or a completion code is passed to the 
program and the program makes its own decision as to what should be 
done. An extension of the latter method is an error return in the 
calling sequence for the subroutine where there may or may not also 
be a completion codet In a real time checkout environment, the decision 
to continue or terminate should probably be left to the program. 

4.4 VALIDATION PROCEDURES 

4,4.1 Role of the Data Bank 

A special data bank, hereafter referred to as the System Data Bank, 
should be available to provide the linkage for subroutine parameter 
validation. It is felt that the subroutine object module should not 
reside in the System Data Bank, but that a description of the number, 
type, and size of parameters be included with the subroutine name and 
revision level. 
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4.4.2 


Role of the Compiler 


The GOAL Compiler will be able to verify Subroutine calling sequences by 
using the descriptive information contained in the System Data Bank. The 
System Data Bank would be used by the compiler without requiring the 
USE/FREE data bank statements in the GOAL program. 

An additional benefit to be derived from this type of system is that 
the compiler could create/update a file which contained a list of every 
program that used each system subroutine. This information would be 
useful in determining the impact of a subroutine error or a subroutine 
change. The restriction could also be made that in order for a system 
subroutine to be successfully compiled, it must be described in the 
System Data Bank. 

4.5 IMPLEMENTATION TECHNIQUES 

4.5.1 Data Bank Update 

A separate configuration control group should be responsible for main- 
taining the System Data Bank. Inputs to this group should be Subroutine 
name, number, type, and limits for each parameter. 

4.5.2 GOAL Compiler 

The Compiler can be used to validate all system subroutine data once 
the subroutine descriptive data has been loaded into the System Data 
Bank. Some limited capability should probably be provided for sub- 
routines that are not system subroutines or subroutines that are not 
defined in the System Data Bank. 

4.5.3 Compilation Output Data 

This area could have a special routine that performs parameter validation 
before executing a subroutine. The only type of validation that should 
be required at this time is parameter limit validation. It would probably 
be more reasonable to perform this type of validation in the system sub- 
routine. 
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SECTION 5.0 
SELECTED APPLICATIONS 


T 



5.0 


INTRODUCTION 


A study was conducted to analyze the overall applicability of the GOAL lan- 
guage to projected launch vehicle/space vehicle ground checkout requirements 
This analysis was accomplished by manually converting selected current ATOLL 
and machine language programs to GOAL, and extrapolating the results from 
this language conversion. This conversion and analysis was performed as 
viewed from the test engineer standpoint. 

5.1 OBJECTIVES 

The primary objective of this study was to verify that the GOAL language is 
capable of perfontiing the tasks required for the efficient ground checkout 
of launch vehicle/space vehicle systems. Emphasis was placed on ascertain- 
ing the applicability and utility of this language in converting test 
engineers' requirements directly into automated, self-documenting procedures 
The major points of detailed analysis centered upon: 

® Applicability - can the required objectives defined in the 
test engineers' specifications be accomplished utilizing 
the GOAL language. 

° Utility - is the high level procedural language GOAL the 
logical or preferred choice for performing those tasks 
associated with automated launch vehicle checkout. 

Adaptability - is the GOAL language adaptable to the 
various disciplines, environments, and test facilities 
encountered in checkout testing. 

® Reliability, flexibility, and efficiency - does GOAL contain 
the inherent characteristics to provide reliability in coding 
and execution, the flexibility to handle widely varying check- 
out requirements, while retaining efficiency in procedure 
generation and documentation. 

5.2 APPROACH 

GOAL is a high level, engineer oriented language designed to be used by test 
engineers to write automated test and checkout procedures directly from test 
specifications and requirements. In order to verify the capability of this 
language to fulfill previously defined objectives, three existing checkout 
programs were converted to the GOAL language. Two of these programs, lAED 
and lATS, were written in the ATOLL language, while the third GEOl was 
written in machine language for the RCA-llOA computer. These programs were 
selected for several reasons. First, lATS and lAED are both ATOLL programs 
executed during the final launch sequence. It can be assumed that there 
will be considerable commonality between these countdown sequences and those 
proposed for future systems. Second, both of these ATOLL programs are inte- 
grated programs, that is, they cover all stages as well as spacecraft. This 
assures that test specifications for the widest possible variety of applica- 
tions are being tested by these programs. 



Thirdly, both of these ATOLL programs have been updated constantly, and use 
many ATOLL operators, such as ARITH that were not available during prior 
ATOLL releases. Fourth, these programs are both quite interactive with the 
operator, giving ample opportunity to verify this technique in GOAL. Finally, 
these programs freely use subroutines, allowing study of parameter passing and 
other techniques. 

The machine language program, GEOl was included in order to study the applica- 
bility of GOAL to checkout programs that were too specialized in nature to be 
written in the ATOLL language. Many techniques, formerly available only to 
the machine language programmer, could be tested using the GOAL instruction 
repertoi re . 

The initial approach to the conversion of the ATOLL programs was the one to 
one approach. That is, for every ATOLL statement there would be one or a 
corresponding group of GOAL statenrents. This allowed verification whether all 
ATOLL statements could be converted directly into GOAL. Once confidence with 
the overall GOAL language structure was gained, variations from the one to one 
technique were introduced. GOAL statements were used replacing many ATOLL 
instructions to test the efficiency of the GOAL language. Various table tech- 
niques were also experimented with in order to gain a fuller understanding of 
the language. No attempt was made to 1005^ verify the conversions from ATOLL 
to GOAL, as size limitations precluded an overall compile on the existing 
GOAL system and with execution of the program not possible even if a compile 
could be obtained. 

The conversion of the machine program GEOl to GOAL was straight forward. 
Descriptive symbolic names were introduced for the program variables, with 
the names being chosen so as to be inherently obvious as to the variables 
replaced. 

Some operations in both ATOLL and RCAllOA machine language could not be per- 
formed directly in GOAL. Others required assumptions as to the executive or 
implementation system that could not be justified at this time. For those 
areas where coding the statement in GOAL was not appropriate for these 
reasons, comment cards were included to indicate those instructions not 
converted. The statement numbers used in all GOAL statements are identical 
to those in the source programs, with the exception of those ATOLL steps 
utilizing six significant digits, which could not be handled by the current 
GOAL Compiler. 

5.3 TECHNICAL SUMMARY 

The conversion of major portions of the lAEU, I ATS, and GEOl programs to the 
GOAL language establishes that GOAL, in its present form, is capable of 
handling most tasks required for launch vehicle ground checkout. The gOml 
language proved relatively easy to learn and use, and tne english language 
nature of GOAL reduces program documentation to a simple task. In general, 
GOAL, when combined with certain assumptions as to its interface with tne 
test system, should be able to nandle directly any task tnat may be required. 
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5.3.1 Language Syntax and Structure 


The checkout language must adapt to the task at hand, that of ground checkout 
of launch vehicles in an engineering environment. It is considered desirable 
that checkout programs be written to conform to the engineering discipline 
when possible, rather than to utilize highly specialized programming techniques. 
Typical ATOLL programs provide test checkout by commanding the system under 
test to an initial configuration, issuing a specific stimulus to that system, 
and comparing test results with predetermined conditions. Proper verification 
of this data usually results in program progression, while an error or abnormal 
condition usually results in the display of an error message and a program 
branch to an error routine. 

These tasks can be accomplished quite effectively using GOAL, as is shown in 
the following example. 


$*♦ ST 12A INVERTER POWER ON; 

STEP02 SET (ST12^J FUNCTIONS TO (TEST); 

SET <MD01313> t <MD01314> TO ON FOR I SEC; 

STEP03 VERIFY <MDI2l2l> IS ON WITHIN 100 MSEC ELSE DISPLAY EXCEPTIONS 
(♦lU ST12A INVERTER DIO NOT COME ON WHEN COMMANDED) 

TO <CRT«A6> t <CRT-A7> t <CRT-A9> AND GO TO STEP2013; 

STEPOA DISPLAY TEXT (lU ST124 INVERTER ON NORMALLY) 

TO <CRT-A6> f <CRT-A7> « <CRT-A9>; 


This sequence is typical of current ATOLL application programs. The attributes 
of GOAL are quite obvious when reading this example. The test progression is 
apparent in this example, even to one with no training in GOAL. No logic 
ambiguity exists, for example, as to what messages will be displayed when 
testing on the state of MDI2121. 

Many instructions proved extremely useful and versatile during this study. The 
VERIFY prefix was the most widely used, as when combined with an execution 
statement allowed the testing of an external sensor, the display of an appro- 
priate message, and the performance of the required response, all without 



program branching. This type of combined operation greatly simplifies 
program logic and materially reduces chance for error. The second most 
widely used operator was 'SET', and, when used for multiple discretes, 
or with its time option proved versatile and uncomplicated. In general, 
the operator set was applicable to solving the problem at hand with little 
need to comment. In certain respects, however, the study revealed some 
areas where further study might lead to language enhancements. 

5.3.1. 1 External References. A symbolic name that references hardware 
items or data not locally located in a particular GOAL program are denoted 
by the use of angle brackets, such as <MDI1313>, while names that are local 
to that program are denoted by parenthesis (ABCD). This is quite useful, 
as external references are immediately obvious, and one level of redundancy 

is provided by the required verification of the usage of an external reference 
by its assignment in the data bank. The GOAL language uses separate operators 
for internal and external data. The VERIFY prefix provides an example of 
this. When internal names are referenced, the IF/THEN option must be utilized, 
requiring positive logic and deleting the output exception capability. When 
testing external designators, the full capabilities of this powerful prefix 
are brought to bear, including the output exception compounded with a 
response action, and either positive or negative logic. It would seem useful 
if the full power of this VERIFY prefix were made available to all types of 
variable testing. These comments apply equally well to most other operations 
where a distinction is made between internal names and external references. 
Further advantages could be obtained by reductions in the syntax set, and 
hence improve the ease of learning/using the language. 

5. 3. 1.2 Syntax Documentation . The GOAL language is thoroughly documented 
by the use of syntax diagrams. These diagrams represent a new technique and 
quite adequately document the language. However, in a language with this 
large and complex instruction set, the number of syntax diagrams used tends 
to increase the learning time for the language. It might be possible to 
reduce the number of required syntax diagrams by: 

a. Eliminating obvious diagrams, such as LETTER and NUMBER 

b. Combining others, such as LIST NAME, COLUMN NAME, and PROGRAM NAME 

c. Reorganizing the syntax handbook into a users guide, introducing 

a few ground rules, such as "are leading zeros allowed on step numbers?" that 
may not be obvious or easily represented by syntax notation. 

5. 3. 1.3 Subroutines and Macros . These are programming aids more familiar 
to the programmer than the engineer. Subroutines however, have been success- 
fully used by engineers in many ATOLL procedures. One feature of subroutines 
that is not natural to the engineer is the method of parameter passing. The 
concept most easily understood by an engineer is the 'comnon' storage location 
where required data is stored, and programs or subroutines can access it, such 
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as the current arithmetic cell concept in ATOLL. This concept is easy to 
learn, would reduce the required data declarations in both subroutines and 
programs, and could be adapted to the needs of parameter passing for con- 
currently executing procedures. 

The use of macros was also studied during this program conversion. Macros 
are a programming aid that are generally unfamiliar to a test engineer. 

Most current test and checkout programs are brute force procedures, that 
lack the required repetition of complex sequences that lend themselves to 
macro usage. In fact, most areas studied as candidates for macro implementa- 
tion usually turned out to be more properly included as part of the executive 
or operating system. 

5. 3. 1.4 Table Usage . Much time was spent trying to effectively use tables 
to perform complex tasks. These included large tables to be used similar to 
profile tables, varying to small tables containing only two rows. In general, 
table techniques developed were not al'together successful. For example, two 
general methods exist for determining if a switch is in auto. 


TABLE DECLARE METHOD FOR SWITCH POSITION TESTING; 

DECLARE STATE TABLE (SI HYD SYS 1 SW) WITH 2 ROWS AND 3 COLUMNS 


TITLED 

(OFF) 

, (AUTO) 

f 

(ON) 

WITH ENTRIES 

<LDI1572> 

OFF 

, OFF 

f 

ON 

* 

<LDI1573> 

ON 

, OFF 

f 

OFF 

• 

f 

STEP2UD VERIFY (SI 

HYD SYS 

1 SW) FUNCTIONS 

ARE EQUAL 

TO (AUTO) 


ELSE DISPLAY EXCEPTIONS 

(♦SI HYD SYS I SWITCH NOT IN AUTO) TO <CRT-0>; 


$** COMPOUND METHOD FOR SWITCH POSITION TESTING, NO DECLARATIONS NEEDED; 

STeP2IlO VERIFY <LDI1572> , <L0I1573> IS OFF ELSE DISPLAY EXCEPTIONS 
(SI HYD SYS 1 SWITCH NOT IN AUTO) TO <CRT-0>; 



It is obvious that method 2, compounding the test parameter, is shorter 
to code. Likewise it is easier to debug as the sensor notation is avail- 
able at the equation, and no reference to the table is required. It can 
be said that for most operations allowing compound operations, the 
referencing of variables with like attributes and states should not be 
accomplished using table techniques. 

Table techniques are more applicable where large numbers of variables are 
involved and the required state may vary during the program. lAED was 
typical of a program where the desired state of discretes in a table was 
modified continually throughout the program, while in lATS the required 
state was established only once in the program. Study of the listings will 
show the techniques used for each. Two points did come to light during the 
study of table techniques. First, the applicability of system output 
messages to table compares would greatly reduce the workload of producing 
the required messages. Secondly, the inclusion of a "don't care" initial 
declaration for a particular row and column could reduce the requirements 
for row inhibit and enable, which can possibly lead to errors if extensive 
program branching is undertaken. An example of this is shown at the end of 
the I ATS conversion. 

5. 3. 1.5 Data Banks . The general concept of the data bank tends to reduce . 
the GOAL procedure writing workload. It became obvious during the program 
that further data bank refinement is desirable. In many cases it should be 
possible to status a function designator defined as a load, such as to 
check the set point of a thermostat or the level for a tank fill. S^bolic 
names might also be taken from the data bank at compile time, to be included 
in system messages outputted as the result of table compares. The data bank 
also might include definition of system variables to be used for the passing 
of analog information from program to subroutine. Finally, a hierarchy of 
data banks should be studied, as the usage of data bank structures is not an 
exact replacement for the DISA operator. Along with this, any function 
designator classed as a sensor should be available to any GOAL program. 

5. 3. 1.6 System Interface . One area where definitions are necessarily unclear 
is the interface with the test system. Assumptions were made to expedite 
program conversion areas where these assumptions were made included interface 
with the count clock and GMT, the availability of millisecond timers, the 
availability of system routines for hardware devices, (i.e., switch selector), 
and the availability of analog communication cells. Other ATOLL operators 
invoked special routines that were assumed to be available in the executive 
system, and no special notation has been made of these. 

5. 3. 1.7 Miscellaneous Comments . Many other minor comments concerning the 
GOAL language have been listed in tabular form on the GOAL Syntax Summary. 

These are grouped according to syntax number, and in general do not constitute 
significant changes to GOAL. However, many, such as the inclusion of a NO-op 
statement (syntax 73) and the inclusion of basic math in the relational 
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formula (syntax 62) represent minor modifications that would simplify 
procedural coding. Others, such as the comments under syntax diagrams 39 
and 42 are included only for completeness. 

5.3.2 Overall Summary 

In general, this program conversion effort established the effectiveness of 
GOAL in meeting program objectives. No serious flaws or concepts were 
uncovered during the study. The language is impressive for its self-documenta- 
tion and the overall lack of ambiguity of its various operators. However, 
programs tend to become lengthy when written in GOAL, and considerable key- 
punch effort must be expended. Minor improvements, implementation of short 
form coding, and effective interface with the test system should establish 
GOAL as a language well suited to launch vehicle checkout. 
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GOAL SYNTAX SUMMARY 


DIAGRAM 
ACTIVATE TABLE 


APPLY/ANALOG 

ASSIGN 

AVERAGE 

BEGIN DATA BANK 
MACRO 
PROGRAM 
SUBROUTINE 

BINARY NUMBER 

CHARACTER 
CHARACTER STRING 

COLUMN NAME 
COMMENT 

COMPARISON TEST 
CONCURRENT 


SUMMARY 


Enables all or part of a table previously 
inhibited, allowing table to be modified 
somewhat similar to a profile table. In 
practice exact table configuration may be 
unclear. 

This operation is hardware and system depen- 
dent, with no counterpart in current techniques. 

Useful only for internal names, counter- 
part to analog LET and external reference 
SET and ISSUE. Perhaps combining these 
to one operator desirable. 

N/C 

Comments in text body for macros and sub- 
routines. 


Numeric formula does not allow use of binary 
and other number patterns unless declared 
and Initialized. 

ASCII 

Syntax diagrams, such as this, expand size 
of manual & number of diagrams for user. 

Some reduction is desirable. Use of 'rules' 
could help. 

N/C 

N/C 

Comments under 44 and 62. 


Limited operations allowed by concurrent 
prefix require 'tricks' to do many required 
tasks. Perhaps concurrent should be an 
allowable prefix. For example, why allow 
'and' part of 'VERIFY' syntax and not 'ELSE' 
option. 



GOAL SYNTAX SUMMARY 
(Continued) 


SYNTAX 

NO. 

DIAGRAM NAME 

SUMMARY 

17-25 

DECLARE DATA 
NUMERIC LIST 
QUANTITY LIST 
QUANTITY TABLE 
STATE LIST 
STATE TABLE 
TEXT LIST 
TEXT TABLE 

Stating number of rows is redundant if 
table or list filled. 

26 

DELAY 

OR UNTIL option rarely used, as somewhat 
redundant with VERIFY. 

27 

DIMENSION 

Should be part of QUANTITY. 

28 

DISABLE INTERRUPT 

Unsure how interrupt is defined in data 
bank - possibility program could estab- 
lish interrupt. 

29 

END 

Allow program/subroutine name on this card. 

30 

EXPAND MACRO 

Macro statements programmer oriented, not 
natural to engineer. Few tasks so repeti- 
tive to require use. Execute option 
reduces self documenting feature of GOAL. 
Parenthesis required on macro name when 
defined, but not when used. 

31 

EXTERNAL DESIGNATOR 

Parenthesis on table name of functions 
limits quick visibility of external items. 

32 

FREE DATA BANK 

N/C 

33 

FUNCTION DESIGNATOR 

Special characters, other than are 

unusual in names of this sort. 

34 

GO TO 

NO-OP statement. Desirable for target. 

35 

HEXADECIMAL NUMBER 

N/C 

36 

INDEX NAME 

N/C 

37 

INHIBIT TABLE 

Needed due to type of table operation, 
comments under 1 and in text. 
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GOAL SYNTAX SUMMARY 
(Continued) 


SYNTAX 


NO. 

DIAGRAM NAME 

SUMMARY 

38 

INTEGER NUMBER 

N/C 

39 

INTERNAL NAME 

Not sure of grouping for table. 

40 

ISSUE DIGITAL 
PATTERN 

Confusing operator, external designator 
may be a state, etc. Feel issue/set/ 
apply/let equal should be reevaluated. 

41 

LEAVE 

Redundant to perform subroutine/program? 

42 

LET EQUAL 

EQUAL TO option reads LET (ABC) EQUAL 
TO 5. Reevaluate multiplicity of 'SET' 
operators . 

43 

LETTER 

N/C 

44 

LIMIT FORMULA 

Internal name may be a table. Binary, 
hex, etc., not permitted unless declared 
as an internal name. 

45 

LIST NAME 

N/C 

46 

MACRO LABEL 

N/C 

47 

NAME 

should be only symbol allowed (same 
as for FUNCT DESI6). 16 character names 
should be sufficient. 

48 

NUMBER 

N/C 

49 

NUMBER PAHERN 

N/C 

50 

NUMERAL 

N/C 

51 

NUMERIC FORMULA 

Math for number patterns not allowed. 
Quantity must be in parenthesis here, 
which is not consistent. Parenthesis 
around imbedded numeric formula unclear. 

52 

OCTAL NUMBER 

N/C 

53 

OUTPUT EXCEPTION 

Very useful instruction. 
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GOAL SYNTAX SUMMARY 
(Continued) 


SYNTAX 

NO. 

DIAGRAM NAME 


SUMMARY 

54 

PARAMETER 

N/C 


55 

PERFORM PROGRAM 

N/C 



56 

PERFORM SUBROUTINE 

Parameter passing (positional data) is 
not natural to engineers, perhaps use of 
arithmetic cell technique applicable. 

57 

PROCEDURAL STATEMENT 
PREFIX 

Any executable statement, including 'END 
should allow statement number. 

58 

PROGRAM NAME 

N/C 

59 

QUANTITY 

Parenthesis required in 51 inconsistent 
with usage in other diagrams. 

60 

READ 

N/C 

61 

RECORD 

External devices (CRTs, etc.) locally 
declared. Display package (clear, line 
number, etc.) may require more sophisti- 
cation. Method of providing continuous 
monitor of parameters (other than concur 
rently) may be desirable. 

62 

RELATIONAL FORMULA 

Math may be desirable such as (A) is = 
(B) + 5, as when checking pressure 
changes or current changes during appli- 
cation of loads. 

63 

RELEASE CONCURRENT 

N/C 

64 

REPEAT 

N/C 

65 

REPLACE 

N/C 

66 

REQUEST KEYBOARD 

N/C 

67 

RESUME 

Same comments as 41 . 

68 

REVISION LABEL 

N/C 
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GOAL SYNTAX SUMMARY 
(Continued) 


SYNTAX 


NO. 

DIAGRAM NAME 

SUMMARY 

69 

ROW DESIGNATOR 

N/C 

70 

SET DISCRETE 

See comments syntax diagram 3. 

71 

SPECIFY 

N/C 

72 

STATE 

N/C 

73 

STEP NUMBER 

6 digits desirable, 4 step, 2 substep, as 
step numbers useless for documentation 
unless sequential. NO-OP operator desir- 
able as target statement. 

74 

STOP 

Restart labels and description will be for- 
matted on CRT, as to what each restart label 
accomplishes is meaningless to an operator 
without this description. Thus display 
portion redundant, and only way to delete thi 
output is to use unrestricted restart. 

75 

SUBROUTINE NAME 

Revision label option. 

76 

SYMBOL 

See Syntax 10. 

77 

TABLE NAME 

Can be external designator. 

78 

TERMINATE 

N/C 

79 

TEXT CONSTANT 

Use of parenthesis confusing. 

80 

TIME PREFIX 

Implementation dependent, see text. 

81 

TIME VALUE 

N/C 

82 

USE DATA BANK 

Data Bank not total replacement for DISA 


Operator, Hierarchy of Data Banks should 
be studied. Sensor Data Bank should be 
universal. Should be able to read value 
of a 'load' if in table form in computer. 
Need analog communication cells between 
programs . 
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SECTION 6.0 


SYSTEM MACROS 



6.1 INTRODUCTION 

Several 'system' type macros were written during the course of this study 
for the purpose of establishing macro candidate types for inclusion in the 
system data bank. This investigation was centered around two classes of 
Macros. The first type of macro was used to provide a simple interface 
between procedural requirements and the operational characteristics of 
Test hardware. The second type was used to ease the coding burden for long 
and/or repetitious tasks. The macros written during this investigation are 
included with this report. 

6.2 OBJECTIVES 

The objective of this investigation was to provide an overview of the re- 
quirements for macro routines to be included in the GOAL system data bank. 

It was considered desirable to establish those areas where macros would have 
the greatest applicability, and to investigate the interface between these 
macro types and the test engineer writing tne procedure. The analysis was 
performed by outlining and coding into macros certain tasks performed during 
Apollo/Saturn checkout. These tasks included repetitious steps performed by 
automated procedures during vehicle checkout, and specific system responses 
to Atoll operators that might not be apparent to the test engineer. The 
application of specific system macros is dependent upon the final definition 
of the test system, so generation of final or 'operational' macros was not 
attempted. 


6.3 APPROACH 

The basic objective in creating the GOAL language was to define a flexible 
test engineer oriented language to provide ground checkout of space vehicles. 
The wide range of attributes and requirements of this language have been 
discussed elsewhere. However, one area that can lead to efficient programming 
in the GOAL language and reduce the coding effort is the judicious application 
of programming aids, such as macros. Macro techniques are not unique to GOAL, 
but are included in most progratnner oriented languages. The applicability of 
macros to the engineering oriented language, GOAL, was studied from several 
aspects. 

First, macros by themselves do not increase the capabilities of the language. 
What they do accomplish is to ease the burden on the test writer by reducing 
coding requirements. It is also natural that with this ease on coding burden 
the test engineer will be better able to produce a better test program. 

Second, other programming aids exist to ease this coding workload which must 
be considered. The REPEAT statement in GOAL is an example of this. REPEAT 
allows segments of a GOAL program to be executed over and over again, regard- 
less of their location in the overall program. This is quite valuable, as 
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repetitive portions of the program need not be recopied, reducing both 
programmer workload and program object code size. REPEAT, when used with 
index variables, even allows calculation of different parameters on each 
pass, as may be required for testing of five separate engines. Macros were 
thus studied as to their relative applicability when compared to other 
techniques. 

Thirdly, many tasks that can be handled by macros can also be handled by 
subroutines or subprograms. This subject is one that is discussed in many 
programming texts, and in GOAL the tradeoff between each method does not 
lend itself to a simple answer. 

Finally, several tasks considered as candidates for macro subroutines must 
also be considered as to their inclusion in the system executive program 
package. 


6.4 SUMMARY 

Two distinct areas for potential system macro application were denoted during 
this investigation. First, a class of macros was generated to assist with 
the interface of specialized test hardware requirements with the overall test 
system. Secondly, a class of macros was generated that can be defined solely 
as programming aids. 

6.4.1 Hardware Interface Macros 

During vehicle checkout, the test system must interface with many types of 
specialized hardware items. One example of this is the switch selector. 
Currently ATOLL programs use a single operator to issue a switch selector 
channel command. The operating system then invokes a special procedure to 
carry out the required command and associated system validation. This pro- 
cedure was coded as a macro, and is included as example 6-1. 

Another area of hardware interface that is applicable to macro programming is 
the repetitive powering on and off of similar systems. The various auxiliary 
and stage power supplies are typical candidates for this application. The 
power supplies included have different voltage and load current capacities, 
but common macros can be generated. Macros covering power on, power off, and 
the backup battery switchover test are included as examples 6-2, 6-3, and 6-4. 

6.4.2 Programming Aid Macros 

A second class of macros investigated included those that were specifically 
written to reduce programming workload. These macros were aimed directly at 
the coding tasks that were so repetitive in nature that relief was suggested. 

The current LCC firing room configuration requires that most switches communica- 
ting with the RCA-llOA be three way switches. This allows for manual as well as 
automated control of the test item. However, the position of the switch can no 
longer be determined by a simple on-off test, and a table declaration is 
suggested. A simple macro was generated to perform this declaration task, and 
is included as example 6-6. 
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Another programming aid macro was generated to assist with bookkeeping. 

Many times in testing it is desirable to specifically note exception items 
in a table and display the results on request. The procedure to accomplish 
this is not difficult, but a system type macro was written to allow easy 
insertion of this technique in the program as example 6-6. 

6.5 CONCLUSIONS 

System macros were generated for several programming functions. There is no 
question that the macros generated do ease the test engineer's burden. These 
macros also establish that, once the engineer becomes familiar with the para- 
meter passing, macros should become a useful tool. 

Macros were especially applicable when used for the task of hardware interface. 
They should be applicable to the task of power application and removal of many 
types of hardware systems. Macros should also be useful in providing the inter- 
face between the test program and specialized hardware. They are especially 
advantageous for this application as they are not included as part of the 
system executive, and thus lend themselves to testing at other locations, as 
well as adapting to local configuration control. 

Macros intended primarily as programming aids can be just as useful. One task 
already identified is the reduction in coding requirements for the test engineer, 
and macros can play a significant role in that reduction. 

In summary, the proper use of macros should lead to more efficient and precise 
checkout procedures. Macros should also lead to more program standardization, 
as tasks will be performed in an identical manner regardless of the individual 
test engineer. 

One test that cannot be completed at this time is a tradeoff between various 
programming techniques. Macros, subroutines, the REPEAT statement, and 
specialized system executive programs are all logical candidates when con- 
sidering techniques for more effective and efficient GOAL programming. The 
studies required to complete this task must await further definition. 
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$ SECTION 6 EXAMPLES - SELECTED SYSTEM MACROS? 

$ THE FOLLOWING ARE SELECTED APPLICATIONS OF CANDIDATE TYPE SYSTEM 
$ MACROS. THESE DO NOT CONSTITUE RECOMMENDED APPLICATIONS, BUT 
$ SERVE TO ILLUSTRATE THOSE AREAS WHERE MACRO TECHNIQUES MAY BE 
$ USEFUL. THESE MACRO APPLICATIONS ARE REPRESENTATIVE OF CURRENT 
i CHECKOUT PROCEDURES AND DO NOT REPRESENT EXTRAPOLATIONS AS TO 
$ FUTURE CHECKOUT TECHNIQUES; 

$ IN GENERATING THESE MACROS BRANCHING WAS KEPT TO AN ABSOLUTE 
$ MINIMUM, TO REDUCE THE NEED OF PASSING UNIQUE STEP NUMBERS AS 
% PARAMETERS.; 


S EXAMPLE 6 - I SWITCH SELECTOR CHANNEL ISSUE; 

i THE FOLLOWING IS AN EXAMPLE OF A HARDWARE ORIENTED MACRO APPLICATION. 
% THE FUNCTIONS PERFORMED IN THIS MACRO ARE NOW PERFORMED AS PART OF 
$ THE SYSTEM EXECUTIVE. HARDWARE ORIENTED MACROS SUCH AS THIS BECOME 

$ ATTRACTIVE WHEN INFREQUENTLY USED HARDWARE FUNCTIONS ARE ENCOUNTERED, 
S NOT JUSTIFYING INCLUSION IN THE SYSTEM EXECUTIVE, DR IF SPECIALIZED 
$ HARDWARE TEST REQUIREMENTS MUST BE MET AT VARIOUS LOCATIONS OR UNDER 
S DIFFERENT TEST SYSTEM EXECUTIVES; 


BEGIN MACRO SWITCH SELECTOR ISSUE , STAGE , CHANNEL ♦ RECYCLE , ERROR; 


%** THIS MACRO REQUIRES FOUR ENTRIES:; 


$ 

$ 

$ 

$ 


1. STAGE SELECTED, SIB, SIVB, SIU; 

2. CHANNEL TO BE ISSUED IE CHAN38; 

3. UNIQUE STEP NUMBER FOR ERROR ROUTINE (ERROR); 

4. UNIQUE STEP NUMBER FOR RECYCLE OPTION (RECYCLE); 


$** NOTE - UTILITY FLAG <FLGO> IS USED IN MACRO TO DETECT ERRORS; 

$ UTILITY FLAG <FLG1> IS USED TO INDICATE RECYCLE; 

(RECYCLE) SET <FLG1> TO ON; $SET RECYCLE FLAG; 

SET <FLGO> TO OFF; SRESET ERROR FLAG; 

VERIFY <IU SW SEL PWR> IS ON ELSE DISPLAY EXCEPTIONS 

(lU SWITCH SELECTOR POWER IS OFF) TO <CRT-0> 

AND SET <FLGO> TO ON; 


VERIFY <LVDA-ESE SW> IS OFF ELSE DISPLAY EXCEPTIONS 
(LVDA-ESE SWITCH IS IN LVOA POSITION) TO <CRT-0> 

AND SET <FLGO> TO ON; 
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$ SECTION 6 EXAMPLES - SELECTED SYSTEM MACROS; 

S EXAMPLE 6 - I SWITCH SELECTOR CHANNEL ISSUE (CONT> ; 


VERIFY <SW SEL MANUAL SELECT> IS OFF ELSE DISPLAY EXCEPTIONS 
(SWITCH SELECTOR IS IN MANUAL MODE) TO <CRT«0> 

AND SET <FLGO> TO ON; 

VERIFY <(STAGE) SW SEL INHIBIT> IS OFF ELSE DISPLAY EXCEPTIONS 
((STAGE) SWITCH SELECTOR INHIBIT IS ON) TO <CRT-0> 

AND SET <FLGO> TO ON; 

VERIFY <(STAGE) SW SEL PWR> IS ON ELSE DISPLAY EXCEPTIONS 
((STAGE) SWITCH SELECTOR POWER IS NOT ON) TO <CRT-0> 

AND SET <FLGO> TO ON; 

VERIFY <(STAGE) SW SEL ALL ZEROS> IS ON ELSE DISPLAY EXCEPTIONS 
((STAGE) SWITCH SELECTOR ALL ZEROS NOT ON) TO <CRT-0> 

AND SET <FLGO> TO ON; 

VERIFY <FLGO> IS OFF ELSE GO TO (ERROR); $ERROR-NO ISSUE ; 

%** SWITCH SELECTOR CHANNEL ISSUE ROUTINE; 

SET <(STAGE) STG SELECT> TO ON FOR 100 MSEC; 

WAIT AO MSEC; 

VERIFY <(STAGE) STAGE SEL£CT> IS ON ELSE DISPLAY EXCEPTIONS 
((STAGE) SWITCH SELECTOR STAGE SELECT FAILED) TO <CRT-0> 

AND SET <FLGO> TO ON; 

VERIFY <FLGO> IS OFF ELSE GO TO (ERROR); 

SET <SW SEL (CHANNEL)> TO ON FOR 100 MSEC; 

WAIT 50 MSEC; 

VERIFY <SW SEL ERROR> IS OFF ELSE DISPLAY EXCEPTIONS 
(SWITCH SELECTOR ERROR DURING ISSUE OF (CHAN)) TO <CRT-0> 

AND SET <FLG0> TO ON; 


$♦* ERROR DETECTION ROUTINE; 

(ERROR) VERIFY <FLG1> IS ON ELSE SET <FLG0> TO OFF; 

SET <FLG1> TO OFF; 

VERIFY <FLG0> IS OFF ELSE DISPLAY EXCEPTIONS 

(SWITCH SELECTOR FUNCTION NOT ISSUED FOR ABOVE REASONS) 

TO <CRT-0>; 

VERIFY <FLGO> IS OFF ELSE DISPLAY EXCEPTIONS 
(ENTER (RECYCLE) TO RETRY, (ERROR) TO CONTINUE) 

TO <CRT-0>; 

VERIFY <FLGO> IS OFF ELSE STOP AND INDICATE RESTART LABELS 
(RECYCLE), (ERROR); 


END MACRO; 
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$ SECTION 6 EXAMPLES 


SELECTED SYSTEM MACROS; 


$ EXAMPLE 6-2 AUXILLIARY AND STAGE POWER SUPPLY ON; 

i THIS MACRO IS AN EXAMPLE OF A TYPICAL POWER ON PROCEDURE THAT CAM 
$ BE HANDLED BY A SYSTEM MACRO. THE ADVANTAGE TO USING A MACRO IS 
$ THE SPEED OF EXECUTION IF ONLY ONE OR TWO SUPPLIES ARE TURNED ON 
$ IN A GIVEN PROCEDURE. IF SEVERAL SUPPLIES ARE MANIPULATED, 

$ SUBROUTINES MIGHT BE ADVANTAGEOUS TO REDUCE OBJECT SIZE. 

BEGIN MACRO POWER ON , (SUPPLY) , (ERROR); 

$ PARAMETERS PASSED TO THIS MACRO; 

$ 1. SUPPLY - POWER SUPPLY DESIG IE 6D100; 

S 2. ERROR - UNIQUE STEP NUMBER FOR BRANCH ON ERROR COND; 

SET <FLGO> TO ON; SSET ERROR FLAG; 

VERIFY <(SUPPLY) CBl> IS ON ELSE DISPLAY EXCEPTIONS 
((SUPPLY) MAIN CIRCUIT BREAKER IS OPEN) TO <CRT-0> 

AND GO TO (ERROR); 

SET <(SUPPLY) START SW> TO ON FOR .5 SEC; 

VERIFY <(SUPPLY) SPLY ON I> IS ON WITHIN 1 SEC ELSE DISPLAY 
EXCEPTIONS ((SUPPLY) POWER SUPPLY DID NOT COME ON) 

TO <CRT-0> AND GO TO (ERROR); 

$♦* VOLTAGE ADJUST ROUTINE, VOLTAGE JUST ABOVE SET WITH NO LOAD; 

VERIFY <(SUPPLY) VOLTS> IS LESS THAN (SET VOLTS) 

ELSE SET <(SUPPLY) VOLTS DECRS> TO ON; 

WAIT 30 SECS OR UNTIL <(SUPPLY) VOLTS> IS LESS THAN 
(SET VOLTS); 

SET <(SUPPLY) VOLTS DECRS> TO OFF; 

VERIFY <(SUPPLY) VOLTS> IS LESS THAN (SET VOLTS) 

ELSE DISPLAY EXCEPTION ((SUPPLY) VOLTAGE CANNOT BE SET) 

TO <CRT-0> AND GO TO (ERROR); 

SET <(SUPPLY) VOLTS INCRS> TO ON; 

WAIT 30 SECS OR UNTIL <(SUPPLY) VOLTS> IS GREATER 
THAN (SET VOLTS); 

SET <(SUPPLY) VOLTS INCRS> TO OFF; 

VERIFY <(SUPPLY) VOLTS IS GREATER THAN (SET VOLTS) ELSE DISPLAY 
EXCEPTIONS ((SUPPLY) VOLTAGE CANNOT BE SET) TO <CRT-0> 

AND GO TO ( ERROR) ; 
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% SECTION 6 EXAMPLES - SELECTED STSTEM MACROS* 

$ EXAMPLE 6-2 AUXILLIARY AND STAGE POWER SUPPLY ON (CONT) ; 
SET <tSUPPLY) OUTPUT PWR SW> TO ON; 

VERIFY <(SUPPLY) OUT PWR ON I> IS ON WITHIN I SEC ELSE 
DISPLAY EXCEPTIONS <(SUPPLY> OUTPUT POWER NOT ON) 

TO <CRT-0> AND GO TO (ERROR); 

SET <FLGO> TO OFF; $RESET ERROR FLAG; 

(ERROR) VERIFY <FLGO> IS OFF ELSE DISPLAY EXCEPTIONS 

((SUPPLY) POWER ON FAILED FOR ABOVE REASONS) TO <CRT-0> 
AND SET <{ SUPPLY) STOP SW> TO ON FOR 1 SEC; 

VERIFY <FLGO> IS OFF THEN DISPLAY TEXT 
((SUPPLY) POWER SUPPLY STARTED NORMALLY) * 

(BUS VOLTAGE IS ) ((SUPPLY) BUS V) TO <CRT-0; 

END macro; 


$ EXAMPLE 6-3 AUXILLIARY AND STAGE POWER BATTERY TEST; 

i THIS MACRO IS USED TO TEST THE BACKUP BATTERY SWITCHOVER FOR 
i AUX AND STAGE POWER SUPPLIES; 


BEGIN MACRO BATTERY TEST (SUPPLY) , (ERROR); 

$ PARAMETERS PASSED TO THIS MACRO; 

$ 1. SUPPLY - POWER SUPPLY DESIG IE 60100; 

t 2. ERROR - UNIQUE STEP NUMBER FOR BRANCH ON ERROR; 


SET <FLGO> TO OFF; SRESET ERROR FLAG; 

VERIFY <ISUPPLY) OUT PWR ONI> IS ON ELSE DISPLAY EXCEPTIONS 
((SUPPLY) POWER SUPPLY NOT ON LINE) TO <CRT-0> AND 
GO TO (ERROR) ; 
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I l«Aip2E 6 -T’’‘'w)<auAl5"SD^s?lGe pSher'batterv test iconti ; 


AfCDTPV ci<;ilPPLY> BAT VOLTS> IS GREATER THAN 2A VOLTS 
DISPLAY EXCEPTIONS {(SUPPLY! BACKUP BATTERY NOT AVAILABLE) 
TO <CRT“0> AND SET <FLGO> TO ON; 

SET <(SUPPLY) BAT EN SW> TO ON; 

VERIFY <(SUPPLY) PK2> IS ON ELSE DISPLAY EXCEPTIONS 
((SUPPLY) BATTERY ENABLE FAILED) TO <CRT-0> 

AND SET <FLG0> TO ON; 

VERIFY <FLGO> IS OFF ELSE GO TO (ERROR)* 

SET <FLG0> TO ON; $SET ERROR FLAG; 

SET <(SUPPLY) OUT PWR ON SW> TO OFF FOR 1 SEC; 

VERIFY <(SUPPLY) BATTERY ON I> IS 

((SUPPLY ) BATTERY SWITCHOVER FAILED) TO <CRT-0> AND 
GO TO (ERROR); 

SET <(SUPPLY) RESET SW> TO ON FOR I SEC* 

VERIFY <(SUPPLY) BATTERY ON l> IS OFF 

exceptions (BATTERY WOULD NOT RESET) TO <CRT-0> AND 

60 TO (ERROR); 


SET <FLGO> TO OFF; 


tRESET ERROR FLAG; 


ABOVE BBASONS, 

TO <CRT-0>; 

END MACRO; 
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S SECTION 6 EXAMPLES - SELECTED SYSTEM MACROS; 


c i:y&MPi F A - 4 AUXILLIARY AND STAGE POWER SUPPLY OFF; 
i TmrMACRD TURNS OFF A TYPICAL POWER SUPPLY. AS IN OTHER MACROS! 
t BRANCHING HAS BEEN KEPT TO A MINIMUM TO REDUCE STEP NUMBER i 
$ PARAMETER PASSING; 

BEGIN MACRO POWER OFF t (SUPPLY) « (ERROR); 

$ PARAMETERS PASSED TO THIS MACRO; te Aninn- 

* 1 SUPPLY - POWER SUPPLY TO BE TURNED OFF IE 6D100, 

$ l\ ERROR - UNIQUE STEP NUMBER FOR BRANCH ON ERROR COND; 


SET <FLGO> TO OFF; 


iSET ERROR FLAG; 


UFRTFY ^(SUPPLY) AMPS> IS LESS THAN 5 AMP ELSE DISPLAY 
EXCEPTIONS (LOAD STILL APPLIED - POWER OFF NOT ATTEMPTED) 

TO <CRT-0> AND SET <FLGO> TO ON; 

VERIFY <(STAG£) LOCKUP EN> IS OFF ELSE DISPLAY EXCEPTIONS 
(LOCKUP ENABLE IS ON - POWER OFF NOT ATTEMPTED) 

TO <CRT-0> AND SET <FLGO> TO ON; 

VERIFY <(SUPPLY) BATTERY EN> IS OFF ELSE DISPLAY EXCEPTIONS 
((SUPPLY) BATTERY ENABLE ON - POWER OFF NOT ATTEMPTED) 

TO <CRT-0> AND SET <FLGO> TO ON; 

VERIFY <FLGO> IS OFF ELSE GO TO (ERROR); 

set <FLG0> TO ON; SSET ERROR FLAG; 

SET <(SUPPLY) OUT PWR SW> TO OFF; 

VERIFY <(SUPPLY) OUT PWR ON I> IS OFF WITHIN I SEC ELSE 
DISPLAY EXCEPTIONS ((SUPPLY) OUTPUT POWER WOULD NOT TURN OF 
TO <CRT“0> AND GO TO (ERROR); 

SET <(SUPPLY) STOP SW> TO ON FOR .5 SEC; 

VERIFY <(SUPPLY) VOLTS > IS LESS THAN I VOLT WITHIN I SEC 
ELSE DISPLAY EXCEPTIONS ((SUPPLY) DID NOT TURN OFF) 

TO <CRT-0> AND GO TO (ERROR); 

SET <FLGO> TO OFF; 

(ERROR) VERIFY <FLGO> IS OFF ELSE DISPLAY EXCEPTIONS 

((SUPPLY) POWER COULD NOT, BE REMOVED FOR ABOVE REASONS) 

TO <CRT-0>; 

END MACRO; 
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$ SECTION 6 EXAMPLES - SELECTED SYSTEM MACROS; 

$ EXAMPLE 6-5 SHORT MACRO FOR TABLE DECLARATIONS; 


$ THE FOLLOWING IS AN EXAMPLE OF A VERY SHORT SYSTEM MACRO TO RELIEVE ;| 
$ THE TEST WRITER FROM THE BURDEN OF CODING THE RELATIVELY LONG ;l 
$ STATEMENT REQUIRED TO DECLARE THE ATTRIBUTES OF THE STANDARD THREE ; 
$ POSITION SWITCH MOST USUALLY REQUIRED FOR DISCRETE CONTROL IN THE h 
S PRESENT LCC FIRING ROOM CONFIGURATION. ;j 


BEGIN MACRO THREE WAY SW, (SW FUNCT NAME) ♦ <FUNCT1> , (STATED , 

<FUNCT2> , (STATE2); 


declare STATE TABLE ISW FUNCT 
TITLED (OFF) 

<FUNCT1> (STATED 
<FUNCT2> (STATE2) 


NAME) WITH 2 

♦ (AUTO) , 

♦ OFF , 
, OFF , 


ROWS AND 3 COLUMNS 

(ON) WITH ENTRIES 
(STATE2) , 

(STATED ; 


END MACRO; 


$ EXAMPLE 6-6 MACRO STORAGE TABLE; 


$ EXAMPLE OF MACRO SKELETON TO RECORD TEST DATA AND INDEX AUTOMATICALLY; 
$ MACRO REQUIRES DECLARE MACRO AND DISPLAY MACRO TO COMPLETE ; 

i ALL REQUIRED TASKS. ; 

BEGIN MACRO DECLARE , (NAME); 

$ THIS MACRO REQUIRED TO ESTABLISH STORAGE FOR DATA; 

DECLARE QUANTITY LIST ((NAME)) WITH 100 ENTRIES; 

DECLARE QUANTITY LIST ((NAME) TIME) WITH lOO ENTRIES); 

DECLARE NUMBER ((NAME) COUNT) = 0.; 

END MACRO; 


BEGIN MACRO STORE , (NAME) » <FUNCT> t (FULL) ; 

$ THIS MACRO REQUIRES THREE PARAMETERS; 

$ 1. NAME - THE NAME OF THE STORAGE TABLE; 

% 2. <FUNCT> - THE FUNCT DESIG TO BE ACCESSED; 

$ 3. FULL - THE UNIQUE STEP NUMBER FOR BRANCH IF FULL; 

LET ((NAME) COUNT) = ((NAME) COUNT) + 1; 

IF ((NAME) COUNT) IS GREATER THAN 100 THEN GO TO (FULL); 

READ <FUNCT> AND SAVE AS ((NAME)) ((NAME) COUNT); 

READ <GMT> AND SAVE AS ((NAME) TIME) ((NAME) COUNT); 

(FULL) IF ((NAME) COUNT) IS GREATER THAN 100 THEN DISPLAY TEXT 
((NAME) TABLE IS FULL - NO FURTHER DATA MAY BE STORED) 

TO <CRT-0>; 

END MACRO; 
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